From owner-xfs@oss.sgi.com Fri Dec 1 06:59:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 06:59:32 -0800 (PST) Received: from MailServer (199-241-81-62.libre.auna.net [62.81.241.199] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1ExLaG028874 for ; Fri, 1 Dec 2006 06:59:22 -0800 Received: from localhost (N2BSolutions [127.0.0.1]) by MailServer (Postfix) with ESMTP id DFA1B17ACA6 for ; Fri, 1 Dec 2006 14:29:35 +0000 (WET) Received: from MailServer ([127.0.0.1]) by localhost (N2BSolutions [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 14792-03 for ; Fri, 1 Dec 2006 14:29:33 +0000 (WET) Received: from correo.adeje.es (firewall [62.81.241.197]) by MailServer (Postfix) with ESMTP id 3B8BD16E9F6 for ; Fri, 1 Dec 2006 14:29:33 +0000 (WET) To: xfs@oss.sgi.com Subject: One problems with mount my partition xfs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: alejanhd@adeje.es Date: Fri, 1 Dec 2006 14:37:40 +0000 X-MIMETrack: Serialize by Router on adeje-lotus/Ayuntamiento de Adeje(Release 6.5.4|March 27, 2005) at 01/12/2006 14:37:40, Serialize complete at 01/12/2006 14:37:40 Content-Type: multipart/related; boundary="=_related 00503D8180257237_=" X-archive-position: 9856 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: alejanhd@adeje.es Precedence: bulk X-list: xfs Este es un mensaje de varios componentes en formato MIME. --=_related 00503D8180257237_= Content-Type: multipart/alternative; boundary="=_alternative 00503D8380257237_=" --=_alternative 00503D8380257237_= Content-Type: text/plain; charset="US-ASCII" Hello, my name is Alejandro, I live in Tenerife, Canary Islands in Spain Sorry for my english is very bad, My question is: In my server Supermicro, with debian sarge2 installed, I have any problems mounting my disc xfs, is posible you send me information of mount partition in xfs??? Thanks --=_alternative 00503D8380257237_= Content-Type: text/html; charset="US-ASCII"
Hello, my name is Alejandro, I live in Tenerife, Canary Islands in Spain

Sorry for my english is very bad,

My question is:

In my server Supermicro, with debian sarge2 installed, I have any problems mounting my disc xfs, is posible you send me information of mount partition in xfs???


Thanks


--=_alternative 00503D8380257237_=-- --=_related 00503D8180257237_= Content-Type: image/jpeg Content-ID: <_2_0461B8380461B6F000503D8080257237> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4QAWRXhpZgAASUkqAAgAAAAAAAAAAAD/ 2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIs IxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjL/wAARCADDAOoDASIAAhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAEC AwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RF RkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZ mqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo 6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL /8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKR obHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RV VldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3 +Pn6/9oADAMBAAIRAxEAPwD3+iiigAooooAKKKKACiiigAooooAKKKyrq8mu Zza2Z2gcSTensKALl1qFrZLm4nSP2JyT+HWs4+I4mIFvZ3cxJwCECj8yadHp 0EB3CMPJnJkfkmlkBx7UAVZfFEkM4ibS52YjPyOrHH4VJH4r08kLcJcWpP8A z2iP8xmomQAkhQCepAxUEuxlKyKGU9mGaYHSQXMN1EJYJUlQ9GRgRUtcC9vJ YSm70yRoZRyyA/K/1FdVoutRavaCQYSZeJEz0PtSA1KKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigCtfTmCAbTh3YIp9Ce9Vd MjSKN06sDyfUVD4lLR6T565IgkV2x6dD/PP4Vz+na8rMr78EgdTTQHXzFQMk 1iajrdhYpm4uY4x/tMOadf3T3enubdwHx+VeVQ2Fyt60urhy5PzStkg/Q+ld +BwccQ25ysl97PPx2Mlh0uVXbOxuPHOmBiIhPN/uRn+tUm8a2rH5ra5UepTP 8qqJ/ZMa/wCsH5iopXsp1MdtE8zHj5Of5V6iwGG/lf3nkf2niG9DbtNYt9Qj aS2kD46juPqO1Zej6u2neNGgRiIpj93tnIqPT4YNDinvbhlQsuNoOePT3NO8 DaHNr+uy65OClrG/yAj7x9q8XF06dOq403dHvYSpOpSUpqzPX6KKK5TpCiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBrIroUdQysM EEcEVx/iLwe07/bNJIilCgNBnCtgYGPQ4rsqry3trAdstxCh9GcCgDzmO28Q 6Zz5HmAdQrA8fTrUX9vQyE/aLZ0buVFdrqPiG2hJjhjW4YfxH7o/x/zzXm3j b4jXejS28FssEE8o3gtAHQrnGD6VcJSi/dInCM1aSNCTUdL27mRv+/IP9KoT 660h8nTtPuJ37EphRWBdfEzWU0Ga587R1uMhYy0LAk98Z+Xge9b/AID8a6nq WmyXMwSfy5fLdvJVcnAPAHbmtpV6trNmUcNSTuok+n+CNa8Q3Mc2rk29sDyv fHoB2r1XT9PttMso7S0jEcMYwAP51yn/AAl15LI32eJMpj90y9RW9omv2+sx sFBiuY/9ZC3Ue49RXO7nQa9FV5L22hOJbiJDuCYLgHceg+tNuNQtLSze8uLi KK2QZaRmwBSAmlmjgiaWWRUjQZZmOAB71xsnxP0RdQkt4m82KNSzSq2OB1IG MH864Hxx4nuPF91DDpc1za6dA2QSARcN2JQjkfWsG0lu7rWGs9Vs7RBHCGRI 1yJB0LZPXngjsfWrjHuB9EWGoW2qWMN7ZTpPbTLuSRDkEVarzfwXqf2LUVsT hYLjgKOAHxwce+MflXpFS1YAooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFNZgqlmIAAySaAMnVtRaMm2gOH/jYfw//AF6xf7PaaJnYgKxxnHNNt761 uQ90Z0ZXYsWB461Tv/ETzgWWnJub+/jp70wL2m6aqIRJh2RtgPb61l+MPBtn r9pC08bB4c7ZI/vKD/Me1dBpqm1giilYu+3943+0eTWqW+XswpgeJ/8ACr7E kCe+uJI15VVQAj8cV6B4e8OWnh/RY7O1h8tMl2yclmPck9TXQukCncIVB9cV WnuAAcmm3cDF1KKKylivUAXB2sBXMX3iGSw1L7fbIUlgfdnoGXPQ+xFa+v6i ksYgDgZ6ZOBXm+o+J/tFudD02ya81WRyodWyoX/Pc8CkIs/8JR4Vi1vXL7X1 n8mf99Y28RYSB2dicEcAgY5NRQ6nNrdnNqN/evPbF3uEthP5ojAH8WON2AO1 VdJ8Nx27NJOYr69YFJJmXdDCO6xg8MfU9Km8IXNskuoaRPaPZ3sL7o7dQNgX uTxzwQc1aVtwOhtY7Wawtb20uYZ450z8hOUOM7eceo571m69cw2xs5EJa8in UxxoMsykhXGB2Kn8wKzNKWWDX9UtrWMQ6a8yxW1ztzFHKVyyA8D1yM8ZGa94 8L+FtI0KyWazTz7i4VXkvJhmSXuOew9AMCk5Acz4U8G30+pW+tauXtYoG321 kD8xPZpPT/d/P0r0mjFFZt3GFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABXGfEDUbhdNGl2m9JbsFWkUH5R6fU12deLax4t1CPxP4hWa5nSztFcwxxxK fnUfLyQR2qoLXUTMTwt4b1u6uo9ItLxWQbjPKVyluu8jdzyzHaQOg574r0zT 7WOxub63tUXFtIEBZQSwxgk8cnIqD4R2E0PguPUrxcXmpSGeTI5Cj5UH0wMj /eq0xNv4pvombaHbd9QRn/Ghu7BF6LJ+YnJPWpy7KODVdHCnbkcU95Bg0hkM 9y4B5rmdf1220qxe6vrhYoh0yev09areK/GdnoiGGP8A0m9PCwpzgnpnH8up rzDUbS61bUUu/EjPNcHmDSonwwHrIR/q19uvvTSvsAzUdb1XxnIyWrmw0eNs S3Mg+8fTjlj6KK6PQ9ChtbUxW8Lw27/6x3/11x7uR91f9gceuak03S2zFLdC PdGMRQxrtihHoq9vr1rbDlZY7eGJ57qTiOGMZZj9Ow960SURCSCC0ty8hSKN B34Arz24vnk8bHV7RSkaRrGokH+t2nnjsCOOfeux1rRNXj1NrfVY1zGqzR28 JLhkyd2fUjiti08JaRqfie3tWgeO2ntfMLxv8wlznJznOfQ0ntcCPTfhnfPP pl9ZOg0uWVbg2dw3MQODkjoSfwPT8PZwABgVFa2sVnaRW0IIiiQIgJzgAYFT Vm3cYUUUUgCiiigAooooAKKKKACiiigAooooAKKKKACiiigAryDxnbPpN5q0 gtoJRet5CpK20N5gzuJHZcfpXr9cd4+8HjxRp0bwMVu7Y5TH8a91/wAKqLsx NGV8LdXeG1uPCl8rJeaad0TFtyyxMSQVbvgk/hj0ONHxrE1ncW2qxnAGIpRn kc5Vv5j8q82jKaboEpjgaO/tZlVbsSGOSJyecnrjA5FSa748uYNRsbjUsoIt iSS2jCVpoDks2OBkZPBA/WqlGzEmdquv2f2cO0m0hSXJbp9PasOfWr7XFdLB zbWH8d4wwWH+wD/6EePY1z934m0LW7S11G5SL7PBuDFJBiU/wKYxyX9R0HvV NrjUfFbbHV7PSkIxAowX9N56fgKIxuMZJdQfang8OxhpckSalL8xXPXZnqff +dX9M0mKzBPzPK5y8rnLMfc1fisrewteixRRjJJ4AFY17cavqiMmmWdzDY4+ e7dCgcf7JPGPerbS2GO1jxJBpxNva4muuh7qn1/wrt/hPot2GudcvyWllXYm 4c84J/QDj3rG8F/D5L/FxclEijPIGGJP17mvZLW3htLZLeBAkaDCgVk3cDA8 XeHptYtFuNOdYdThUrFLnBKnqM9j3H5d6xvDfhnW112z1LV3Cm3hIcB8tLIe MkDIAArvuKMClfSwWFooopAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUlV72/g061a4uX2ovHAySewA9a848QeKb67LS/bG0yxj5GyTax92b+ g/WmlcBvxN0/TdVBtrGdo9TZ1M5iGUwDx5nv6Y59a88mvNM8Ko1nZRfbdUkG GBOT/wACPYe1R6nr1/eBLLRomiilGTelfvjPVc/zNT6L4djsxvYF5mOWduST 7+praMdNRGd4f8MnVdUvNRlgSW7hIM8cKBRGSM/cHbH8WMc9a3H1W68L63a2 9qN9jq4eK4gcFlSQAYlUdQfXtxWVrl22neKdHudNvRbXUZeG5kBIUxED5WYZ 68gD1PaugbwoutaempWxeW+UFx5rcSoegHYDH/16lvoB1mmaNbtpsWt6oYrp 2I+yWSnMUbZP3/7zDBJHQYrm9TtvFVvrc91YQw3UUrB0R2xgjnpkYGewrpdJ Fzby2mm37hpgqyr0IxtwPy2murudJ+TzF4I5BNSnqMxfCmpXUFiU1KOOK8mb fKIzkBj2+n+e9dTFqCt3rz7U7gW93FDuwz5jOPfofzqTSdXkubaKQ5BYdKlg ejLdKe9TxyBq5a1uWfHWtWCVvWkBs0VBFJuHNT0AFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQBU1Cwh1GyltZx8jjqOqnqCPcHmvm/xXo+rHxfL peoyF44mDRgcK6no2K+mSfSub8VeHItcgjuIok/tC2BMDnjcOpQn0P8AOrg7 PUDzO200R2kYC48tcg/0+lPtNPutbi82LfaaYf8AltjEtxjrsHZf9r8q37fw pf6022+jlsNMX70IOJrg+hx9xf1PtXTNpCw20dtbQLFBGoVI0GAoHYU5S7Ac I2g6a2ltYPDiJWOGB+ZCTw2fX3PXBrX8J21rpFqtis3mEsWeVgAWJ/pWnLoc 5fcoIPqKiTw3Os3mL8jeoX/I/SouBn+IJvtPi+F7MkC1tkQsB/FknH5YrrbX xFbz6eY7jEM4XBVzgH6E9aoWvhzyQfl5Y5YnksfU1pJoq4wVyPpSA811SO4u 9aMsSbghzGoOSW7fQDrk1v6Pob21rFERyoANdnFo8SfdjUfhVqOyRP4RQBlW mnlQOK1IrbbVpIgvQVJgUARom2paKKACiiigAooooAKKKKACiiigDG8ReKtH 8KWiXetTzW9s5I85bWWVFPA+ZkUhc5GM4z2zg1HF4w0WSZIpZrqzaRgiG/sZ 7RXY8BVaVFBJPYc1znxt/wCSQ67/ANu//pRHXaatZWWpaRd2eoxo9nNEyzBx xtxyfwoAuUV5H4W8c67N4X8OaNZ2E13r02km9kd1SXbAsvlI7B5YgxcDP38j uDW34l8U+J9M0vwjdfY7fTrrUtWgsL6ymxKVLk/dkVioGEPYnDDoQRQB6DRX IReJNUi8U33hi6OntfpYpqNtchXjiaEyFG3qSxDLj+982f4a5fxV8Tdb8H3F 5Zy2um6tJb6dHqP2mEPbIY3nEOAhMm47mU53AEE+mCAer0mK8/8AH2q+JdJh 0SO2v7GE6h4gtbRWW2clY2+bDZf5vmQg427gcfL3m8VeJ9d8IaDda1dz6TeR WPlLPZ28EiyOGkVN4cyEJkNnaVOOm49aAO7xSYFefXnjjW1uvG9tDZafA/hm GO5VnZ5RcI0bS4ONu0lFHrtJ/iFJP8RZ9PufDd3fQQLpWt6XPfgRqxltvKgE zZOcOCpxgKCCO9AHoW0elGxfSuL8L+JvEuuXlldXHh94dEv7YTx3BMSmDKhl ziZmkDZ67EI4yDyRRtfG+uah4R8T6ulpp9pdeH7y5glgYvOkywIGYBsoQTyA 2D24oA9C2r6CjavoK8f1b4k6jY+IrPVXuIoNGHhiLV3tDbGRnM00aeWCHGHJ IAc5C7jlT1rt73xDqHh680ka79ke31W8Sxj+yxuGt5nUlFYlj5gJUjcAuMjj rQB1OBWW3iTRE15NCOqWv9rPnFmJAZB8m/lRyPlGee1ReLvEcPhLwpqOuzxm VbSPcsecb3JCqucHGWIGccZrzL4ia/deEvF3gnXtfFrNJbx6ixSzjZAS0Kqs fJYn5mA3cdScCgD2fFY3iLxTo/hS0S71mea3tmJHnLayyopyB8zIpC5JGM4z 2zg1S8Oan4nu9SuYNb0NrS12eZBc/uk5zgxsiTyknGCH4B54HGcX42/8kh13 /t3/APSiOgDt9Pv4NTsYry2EwhlBKedA8LYzjlHAYdO45HPQ0t7f2unW/n3k 6QxFlQM56sxwqj1JJAAHJrm28Tai/wAR7jwmlrawoNK/tCC7Z2kJ/eCPDJ8u Pm3cBugByM4HnvifxDq3iWy0AO1lb3WmeOI9MkZYGZJJo87ZQN4ITk5TJJyP mGOQD2LTNUtdXtPtNoZfLDlCJoHhdWHUFHAYfiKuVyOl+INW19tSXSnsCNJu Wsbh5oHAurhEBkCDf+6XcwAJ39/qcu0+JE2s6l4Ri0qyhWy8RwXLJPO7F4JI VYupQAAgEAZ3c89OCQD0KiuJTxL4hbxu/hF4NMjuho41BL4eY6M28R8xZBA3 buN54wc9qyrD4kajd+HfCGvtZ2q2muaimmzW4DF43Z3QSK+cYBjPykE4I57U Aeiz3dtbPClxcRRNO/lxLI4UyPgnauepwCcD0NNvr6202zku7uTy4I8bm2k4 yQBwOepFcT4212/8MWk/iacaXdw6W4C2SRyGZVlkWPf5m/arFT0MfqA3PPND x54o0bw94z8RStp+oW+ma5LYi2eN4mQKYo1ZWDEFeR8hAOSx39iAex0VzEuv X+peJNU0PRGs459LhhkuJbtGkVmlDFYwFZSPlXJbnG4cGo/EWr69o+l3upLN pCCxs3unszHJLJMETc2HDLsG4MASjcYJx0oA6uiqGh6mNa8P6bqqxmIXtrFc iMnO3egbGfbNX6AOe8YeEbfxppH9lXuo39rZOczRWhjXzsEMu4sjHgrkYI98 8Yil8HG9tGstU8Ra1qNi67Htp3hRZBxwzRRI5BxggtggnOa6aigDC1DwrZXl zZXdrNcaZeWURgt7iy2ApEcZTa6shX5RwVOO2K5P4lWLW9l4StbGw1G5S21+ C9nNnayTMsaFjJIxRThiXz6kk46GvSaZNNHbwSTTOEijUu7N0UAZJNAHOXPg XS7+31aPUZ729m1SJYLi4llCv5SklUXYFVQCT0HPfNZniD4W6V4m3PqWqas1 zJarZz3KSRB5oVkWQKw8vaMOobKqp9eta/hPxFca6up29/araahp940MsA7I wDxHqeSjLn/aDdsV0VAGFrfha18QaXYWd9d3hlsJ4rqC8RkWUTxghZD8uwnk nG3bz0rNu/h1pV/YatYXd7qMtnqsouLqAyqA0w2/vAQoIPyL8udvyj5a6+ig Di2+HNs83iGaTXtZeTX4FgvmJtxlVG0bcRYB2bk+jHvghV+G9iJ/Dsj6vqso 0GBre1jcwFXjYbWVx5XOUwhxjhR0bLHqr2/tdOjiku50iWWaOCPccbpHYKqj 1JJFWaAMLRfCtroYgigvLya0tRiztbh1dLUYK/Idoc8Ej5mbAOBisuz+HdpZ aFr+krrWrPDrkrzXcjmDeHk4lK4iAG8cHIOB93aea7GigDi0+GWjqlkHvNQl Ntpv9ks0jRnz7TJIicbMYGRhlCtwOc81sW/he3jvLW5ur29vzZMWs0unUrbn btyNqgscEjLljyea1LH7Z9jj/tDyPtXO/wCz52dTjGeemKsUAVNU0y01nS7n Tb+ETWlzGY5YySMqfccj6iuV1f4Z6Zr76a+q6pqt19gWWOMSPF88cgCsjYj5 G0Y3DD853ZAI7OSRIo2kkdUjQFmZjgKB1JNRWV5BqFjb3trIJLe4iWWJx0ZW GQfyNAFHStDXTG3yX95fSIhjikuyhaKM4OxSqrkfKOWyxwMk4qn4w8I2/jTS P7KvdRv7Wyc5mitDGvnYIZdxZGPBXIwR754x0NVdRkvorCV9Nt4Li8AHlxTz GJG55ywViOM9uvHHUAHP6f4ISy8WReJJde1e9v0tDZH7R5Gx4c7tpCRKeG+b IIORySOKyP8AhUth/wBDHr3/ACFP7Y+9bf8AH3/z1/1P6fd9q3fAXiWbxh4L sNent0t5Loy5iRiQoWRkHJ9lFdJQBh3Hhe3kvLq5tb29sDesGvEtXULcHbty dykqcADKFTwOapT+BNOk1nQNRtru8sl0GMx2VrbmPylVhtcNuQsdy4U/N0GR g5NT+M/EVx4a0N760tVupYf30sR6i3QgzMORyF4H+0y54rfhmjuII54XDxSK HRh0YEZBoA5248GxT+MJfE6axqcF89kbFUj8ny44jzgBoych/nySefVflrHi +FWnQeH9I0WHXNaS00m9+3WmGgLJLnKkkxchWLkA/wB85yMAaGp+KdT034h6 F4ek0+1/s/VvPMV0s7NJ+6i3tlNoC/MQOrZHp0rraAOT1D4e6RqVrrNnc3F+ bHV5vtNzarKAnnfL86nbuB+ReCxX5RxWdf8Awp03UNO1LTm1vWorHU7o3l5B FJCFmnJBLkmIkZKg4BC8DgV2tj9s+xx/2h5H2rnf9nzs6nGM89MVYoA55/Cc P9oJqMGqajb6gYY4Lm6iaPddomcCRShTPJ+ZVU88EUy68Fadd3uoXD3N8E1K 1W0voBN8lxGqlVySC4IDNyrDO45zXSUUAUdG0uLRNHtNLglllgtIlhiaXaWC KMKCQBnAAHTPHOavUUUAFFFFABXL+KtZ00Xth4al1uPTr7UpF27Xj80IDxtD hlO5gEAIOctjJFdRRQB4/qGu2PgT4wWJvPE322PVLU22pG6aBXtWTDQu4jRA AQ2BkdCTkgCr+l+F9G0jWtb8KrpdrLpniLbf2ziIMpiXHmJkdBGSrJ6GUY6G vUaqQ2kovpLq4ljlYApAEjK+WhIJByTkkgZPA+UcCgDx6xttO07wF8UNAuoL eCRb3Ubq2sGQAiHywYZET+6CgIIGBt7YqL4f6lpd9460PTl1OO7tZ/BsEUto 915sX2lSgePyySoYImSoHYkjqa9xooA+cjc6XqOhrEZLW70rTPHw+U7ZIrfT mzjPULAcHr8px7V0fjW60N/CXiB/C+nRWmt6XLClrNbx5ujGHRi8W3LCDaWA IO3CkAAAV7VRQB4Tfanot3qHxZWTVobu3isoZ9P82881Ul8pstFljgiZkA2/ dJVRjgU8a7o66v8ADa8uNZt4P7R0e4TWLoXYjeQeQFXzJAQQRKJApyCGBAwR XudFAHgXhzUbrVPhv4NS61aRdGN3exa7cjZM8TEyNEJfMV1CHcN28EYKnjit PxK2l+GtL8HrZeIr1rP/AISSFo5p7xI4pLQ4aUosW1DCp24JXC5IGFIz7VRQ B4r4tewi+IPirQ7A26i88Izu9jDj97egsynYOsvl4bpnABp/hdtKitfDcN2u mx+FP7DU3wVFWH+0sIr/AGr+HOxWHz9wc84r2eigDkPBbXran4h8s58OfaY/ 7JJz08sebsz/AMs9/wB3HH3scYrNkaAfFLVD4l8v7Ottbf2EJs7S2H83y88e du/u/NtxXoNFAHzl4JeHUPC3hqx1jVksvDCWV2ksuyF40vftRYJN5yPGv7tk ZcgHng817x4atVsvDtnax3N9cxxKUjmv2VpnQMdpYqACMYxxnGM85rVooA4R L/SvGM+sX1l4xa3sbKM2062jWzxiIAlpHMsb4BO4ZBCkJmuF8P8Aiy6uvhR4 h8MaHqUdzrukedbWLRSfvLm1VhiSILySE3Abc8hT3r3WigD58+Jd3Z2V54Ql 8Cy20c4i1BY2hbkyNEisOOs5yRg/MXKg8kV6J4Q0bQjdX8mj65qF/De2zR3i xNBDHE+Ry3kJGyT4ZufvYHPRa7+qWpwahcWoGmX0VncK4O+a385GGCCGXcp7 54YcgdRkEA8I8KvPqvhnwvH4m1eS18Nz2F2z3UyxSI92LtuJmnR0HyY2kgHI ODXt/hq1Wy8O2drHc31zHEpSOa/ZWmdAx2lioAIxjHGcYzzmm+F/Dtp4U8NW Wh2LSNb2qEBpDlmJYsxP1Yk/jWvQAUUUUAFFFFABRRRQAUUUUAFeUaiftGl/ EHWNWVI9Y0maddMmb79rEsCtC0RI+XcxJOOpyDnFer1y2seG7nxBdSwX9tpi 2jfJ9rjXdcvATlocFcIGwAWDHIzwDg0AUZ5E1DRbfWPFNjC+lyaRFcTLLtIs 5wC7nk5ycoFKjIKds1V8L2esXngrwz/wk9ul7CbORb+G5wcbiDFJIJCM7YwQ wOTl89q0Nd0jxFqOvwstjpN3odpse3tJr+SDfMOd8gELghT91c4BG45ONseu 6T4s1aCws5YtKubAoZNRt3vZIPPkJJEW5YWzCOAeAX4BwMhgB3wylu7jwzdT TMzWEmo3LaWXLFvse/8Ad53c464/2dtTal4Y061OoalLcao95e3AcJb6lc26 PIwWNF2xOBwFQFsZwMngcb2kJqCWR/tJLaKcudsFq5eOFBwqqxVSeBnkDkkd AKhutNubvxFY3kk6fYLOKRlgxy07YUOT6Km8D3c+goAxtbtp0/s3TVh1i8sb O3Mlw9lfPFO7DCJufzEZxgyMRuJJUcGseXXrfXNT0LQtAd76xl02TU2We7ce fGGCRpLIwZ9pYtngklQCCMiumlh8VRzXkNvPp08E8jtBczlke0UqNq+Uq4lw 2TkupOaybHwKPC76Td+HIreW60/T305o7uQxLPGziQsXVGIYOGb7pB3Hp1oA dpptNR0GBdD01Y7S21KSHUNLXaANm6N41BIUAPsfHAIXGOa47TNSm/4TqTw3 YDZ4X1HV2itVjDBAtvbbriND0EZkCjA4OJB611EvhLXtO0FtO0WWyaTUb6a9 1eZ7l7Z5DI2WWJljcrn7u48hV45OVvw+G7+a2snlttO02bSpkfTLazlaWGNQ hVgzGND86uykYIGFIyc0Acr4k8QP4W8WL4O01DbWuqixFsIEIW1Es7RShccI CqggDoSSK6V5IPDPj/RNI0+3WCx1m2ut8MSYVZYtriTA4BIdgT3OM81Nc+Dj rBvb/UzDFqtyLcxNAzSJamBt8YBIUvhySThcg4wK0LTSLq416LWtWW3W5toH traK3dnVFZgWckgcsFTjHy4Iyc5oAZ4l8ZaR4W8pL+ZPtEyl4oPPiiZ1BAJD Sui8ZHBbJ7ZqjqfxD0yw8J23ie2sdR1PSJkLtPYxo3kgED51Z1I5yDgHG05x UureHr9fGNt4q0f7LJepYtp89tdyNGksRcOCHVW2kMD/AAnOe1W9Tg159Nit be203UfOEgvBeXLQDa3RE2xPkckZIBwB1JyADD1z4g3elW9iw8LapHJd6nb2 EYnktsSGQ5IQrKwJ2qQMkLkjJGDXbQSNNbxSvDJA7oGaKQqWQkfdO0kZHTgk ehNebv4Q8Z6l4X0Kx1a40eTUdD1K2voJo55St0Itw2SZjBQ4K/MN2eeB37+x OpmWc362ixnb5KwMzEddwYkDPbBAH0oAwvGWmG9m0i5ktr3UbS3uHE2kwRRy Jeb42VfM3sqgIfmyxx7ZIIz9CtrlfDGq6fY38lzeQ6i0j2Uh2taxGRXNqCcc GPKqxOPmyOMVuapZ6+mvQ6ppV1DPbratA+mXUphiZi4bzQ6ox3ADGCpGOmOc 5Fx4b16yi1vUdFlsRr2tXERuJZZGRIIUTYojOxssFHBZcZYkjA2kA47WNVn0 fxvdaf4fj+xaTfPYabdJCpVYLyaYlyu35VfySdxH8RSuzeSDwz4/0TSNPt1g sdZtrrfDEmFWWLa4kwOASHYE9zjPNMtfCd9caMdKurWx022tyk1r9lu3una5 WQSCaRnjQltyjPJ3bmz2rZtNIurjXota1Zbdbm2ge2tord2dUVmBZySBywVO MfLgjJzmgDdooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigD/2Q== --=_related 00503D8180257237_=-- From owner-xfs@oss.sgi.com Fri Dec 1 07:21:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 07:21:36 -0800 (PST) Received: from mail.atipa.com (125.14.cm.sunflower.com [24.124.14.125]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1FLRaG000447 for ; Fri, 1 Dec 2006 07:21:29 -0800 Received: from [192.168.100.199] ([192.168.100.199]) by mail.atipa.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 09:09:40 -0600 Message-ID: <45704570.7020209@atipa.com> Date: Fri, 01 Dec 2006 09:08:32 -0600 From: Roger Heflin User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Issues with XFS on Sles9 sp2. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2006 15:09:40.0781 (UTC) FILETIME=[B98FFDD0:01C7155A] X-archive-position: 9857 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rheflin@atipa.com Precedence: bulk X-list: xfs Hello, I have a customer that has machines whose XFS filesystem quits responding when certain applications are running. The only filesystem that uses XFS is /tmp all other filesystems still respond, anything going to tmp hangs forever. There are multiple machines with a couple of different types of motherboards that have this issue, converting the machines to ext3 eliminates the issues. Under load they were seeing 1-2 events per 24 hours on 100 machines. After the ext3 conversion they have had 0 events on 400 machines in 2 weeks, so it is fairly conclusive that XFS has something to do with it. It is not a hardware problem of the 2 different motherboard with the issue, one uses Opteron+AMDchipset+IDE and the other one uses Opteron+Nvidia+SATA, and the problems are not repeating on any 1 node, the appear to just randomly hit 1 or 2 nodes out of the test set, and the next day it will be a different one. They are using Sles9SP2, currently we cannot go to SP3 as there are some other bad driver issues unrelated to XFS (the issue preventing us from upgrading also appears to be in 2.6.16.x kernel.org kernels so that is a more than just a SLES issue). I have already had long discussions with Suse with less than useful results. Are there any patches that are likely to either produce more debugging or to get rid of this issue? There are no messages in the messages file when the event happens. Below is a sysrq generated stack trace from one of the machines. The issues do not seem to require heavy IO loads (we have verified that the application is not IO intensive), it may be something related to running short on memory, but we don't have any OOM type messages anywhere. The first type of machine to have the issue and where the issue is alot more common has only 4GB of ram, the second type of machine that has recently starting also having the error has 32GB of ram. Roger xfssyncd D 00000000000493e0 0 2760 1 3876 2755 (L-TLB) Call Trace:{:xfs:kmem_zone_zalloc+50} {:xfs:_xfs_trans_alloc+36} {__down_write+117} {:xfs:xfs_ilock+93} {:xfs:xfs_syncsub+2787} {del_timer_sync+80} {del_singleshot_timer_sync+21} {schedule_timeout+254} {:xfs:vfs_sync+40} {:xfs:vfs_sync_worker+25} {:xfs:xfssyncd+378} {:xfs:linvfs_fill_super+0} {child_rip+8} {:xfs:linvfs_fill_super+0} {:xfs:xfssyncd+0} {child_rip+0} res D 000000000000000a 0 16149 1 26319 16151 5825 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {__user_walk_it+70} {vfs_lstat+128} {do_page_fault+536} {sys_newlstat+31} {error_exit+0} {system_call+124} sbatchd D 00000000000493e0 0 16151 1 12686 16149 (NOTLB) Call Trace:{dput+33} {follow_mount+93} {dput+33} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {sys_chdir+138} {sys_select+1244} {system_call+124} gm_mapper D 000000000000000a 0 12686 1 16834 16151 (L-TLB) Call Trace:{:xfs:xfs_trans_log_buf+107} {__down+152} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_trans_getsb+106} {:xfs:xfs_trans_commit+332} {:xfs:xfs_free_extent+204} {:xfs:xfs_efd_init+68} {:xfs:kmem_zone_alloc+75} {:xfs:kmem_zone_zalloc+50} {:xfs:xfs_itruncate_finish+557} {:xfs:xfs_trans_alloc+217} {sysret_signal+28} {:xfs:xfs_inactive+591} {sysret_signal+28} {__pagevec_free+32} {sysret_signal+28} {:xfs:vn_rele+72} {:xfs:linvfs_clear_inode+18} {clear_inode+155} {generic_delete_inode+245} {iput+158} {dput+389} {__fput+270} {filp_close+126} {put_files_struct+115} {do_exit+1010} {__dequeue_signal+501} {sysret_signal+28} {do_group_exit+232} {get_signal_to_deliver+1175} {do_signal+1179} {do_signal+149} {:gm:gm_linux_ioctl+0} {:gm:gm_linux_ioctl+106} {sys_ioctl+1092} {sys_rt_sigreturn+653} {sysret_signal+28} {ptregscall_common+103} lim D 000000000000000a 0 16834 1 16835 17594 12686 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {__user_walk_it+70} {vfs_lstat+128} {save_i387+148} {do_signal+1501} {sys_newlstat+31} {sys_rt_sigaction+148} {system_call+124} pim D 00000000000493e0 0 16835 16834 16870 (NOTLB) Call Trace:{:xfs:xfs_buf_get_flags+877} {:xfs:kmem_zone_alloc+75} {__down+152} {default_wake_function+0} {:xfs:xfs_trans_log_buf+107} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_trans_getsb+106} {:xfs:xfs_trans_commit+332} {:xfs:xfs_dir2_createname+278} {:xfs:xfs_ichgtime+301} {:xfs:xfs_create+1359} {:xfs:linvfs_mknod+521} {:xfs:xfs_iunlock+102} {:xfs:xfs_lookup+119} {:xfs:linvfs_lookup+84} {real_lookup+123} {vfs_create+251} {open_namei+464} {filp_open+87} {sys_open+159} {sys_close+229} {system_call+124} elim.uptime D 00000000000493e0 0 16873 1 14418 18756 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+209} {filp_open+87} {sys_open+159} {error_exit+0} {system_call+124} res D 00000000000493e0 0 14323 16149 26319 (NOTLB) Call Trace:{inet_recvmsg+51} {sock_aio_read+346} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+175} {filp_open+87} {sys_open+159} {sys_socket+104} {system_call+124} acuSolve-gmpi D 00000000000493e0 0 14418 1 14419 16873 (NOTLB) Call Trace:{wait_on_page_writeback_range_wq+324} {__down+152} {default_wake_function+0} {__down_failed+53} {.text.lock.super+169} {do_sync+42} {sys_sync+62} {system_call+124} acuSolve-gmpi D 00000000000493e0 0 14419 1 18864 14418 (NOTLB) Call Trace:{__down+152} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_syncsub+2602} {:xfs:vfs_sync+40} {:xfs:linvfs_sync_super+68} {sync_filesystems+223} {do_sync+49} {sys_sync+62} {system_call+124} mktemp D 00000000000493e0 0 17594 1 17656 16834 (NOTLB) Call Trace:{SHATransform+25} {follow_mount+93} {dput+33} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {sys_mkdir+220} {system_call+124} check_EWNstag D 00000000000493e0 0 17620 1 17751 17656 (NOTLB) Call Trace:{do_sync_write+173} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+209} {filp_open+87} {sys_open+159} {error_exit+0} {system_call+124} Oct/27 07:40 am> sh D 00000000000493e0 0 17959 1 17793 17858 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+209} {filp_open+87} {sys_open+159} {error_exit+0} {system_call+124} From owner-xfs@oss.sgi.com Fri Dec 1 10:50:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 10:50:26 -0800 (PST) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1IoFaG030326 for ; Fri, 1 Dec 2006 10:50:17 -0800 Received: from teal.hq.k1024.org (84-75-119-53.dclient.hispeed.ch [84.75.119.53]) by astra.simleu.ro (Postfix) with ESMTP id C1DE762; Fri, 1 Dec 2006 20:30:46 +0200 (EET) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id D9E0C40A0B6; Fri, 1 Dec 2006 19:30:34 +0100 (CET) Date: Fri, 1 Dec 2006 19:30:34 +0100 From: Iustin Pop To: Christian Kujau Cc: Jasmin Buchert , xfs@oss.sgi.com Subject: Re: mkfs.xfs questions Message-ID: <20061201183034.GA20595@teal.hq.k1024.org> Mail-Followup-To: Christian Kujau , Jasmin Buchert , xfs@oss.sgi.com References: <20061129174553.e0ef3465.jasmin@pacifica.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 9858 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Fri, Dec 01, 2006 at 04:23:41AM +0000, Christian Kujau wrote: > On Wed, 29 Nov 2006, Jasmin Buchert wrote: > >Is there any real advantage of making the log size 32-64 MB and > > From 'man mkfs.xfs': > > If the log is contained within the data section and size isn't > specified, mkfs.xfs will try to select a suitable log > size depending on the size of the filesystem. The actual > logsize depends on the filesystem block size and the directory > block size. > > Otherwise, the size suboption is only needed if the log > section of the filesystem should occupy less space than the size > of the special file. > > So, if you're not limited by very special space restrictions, you won't > need the "size" option. I don't understand how you took that conclusion. The explanations refer to the default log size. I believe the original poster asked about the performance advantage of *raising* the log size above the default values for internal logs, and my impression is that metadata-intensive workloads benefit from increasing the log size (however no hard numbers are available). A while back when mkfs.xfs had more conservative default value, bigger log sizes indeed helped for big filesystems. Regards, Iustin From owner-xfs@oss.sgi.com Fri Dec 1 11:23:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 11:23:16 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1JN9aG002122 for ; Fri, 1 Dec 2006 11:23:09 -0800 Received: from [134.15.160.29] (vpn-emea-sw-emea-160-29.emea.sgi.com [134.15.160.29]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kB1JMIbj61994154; Fri, 1 Dec 2006 11:22:19 -0800 (PST) Message-ID: <457080EA.1010807@sgi.com> Date: Fri, 01 Dec 2006 19:22:18 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> In-Reply-To: <20061130223810.GO37654165@melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9859 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: > >>Dave, >> >>Could you have changed the SB_LOCK from a spinlock to a blocking >>mutex and have achieved a similar effect? > > > Sort of - it would still be inefficient and wouldn't help solve the > underlying causes of contention. Also, everything else that uses > the SB_LOCK would now have a sleep point where there wasn't one > previously. If we are nesting the SB_LOCK somewhere else inside a > another spinlock (not sure if we are) then we can't sleep. I'd > prefer not to change the semantics of such a lock if I can avoid it. That's fair enough and I can't disagree with you. I think the SB_LOCK was/is being abused anyway and was used too genericly (if there's such a word). Using separate locks for specific purposes like you've done with the new mutex is a great start to cleaning this code up. > > I think the slow path code is somewhat clearer with a separate > mutex - it clearly documents the serialisation barrier that > the slow path uses and allows us to do slow path checks on the > per-cpu counters without needing the SB_LOCK. It's certainly an improvement over the original code. > > It also means that in future, we can slowly remove the need for > holding the SB_LOCK across the entire rebalance operation and only > use it when referencing the global superblock fields during > the rebalance. Sounds good. > > If the need arises, it also means we can move to a mutex per counter > so we can independently rebalance different types of counters at the > same time (which we can't do right now). That seems so obvious - I'm surprised we can't do it now. > > >>Has this change had much testing on a large machine? > > > 8p is the largest I've run it on (junkbond) and it's been ENOSPC > tested on a 2.7GB/s filesystem (junkbond once again) as well > as one single, slow disks. > > I've tried and tried to get the ppl that reported the problem to > test this fix but no luck so far (this bug has been open for months > and most of that time has been me waiting for someone to run a > test). I've basically got sick of waiting and I just want to > move this on. It's already too late for sles10sp1 because of > the lack of response. If it's important to them they'll test it. If the change doesn't fix their problem then I'm sure we'll hear from them again. > > >>These changes wouldn't apply cleanly to tot (3 hunks failed in >>xfs_mount.c) but I couldn't see why. > > > Whitespace issue? Try setting: > > $ export QUILT_PATCH_OPTS="--ignore-whitespace" > > I'll apply the patch to a separate tree and see if I hit the same > problem.... > > >>The changes look fine to me, couple of comments below. >> >>Lachlan >> >> >>@@ -1479,9 +1479,11 @@ xfs_mod_incore_sb_batch(xfs_mount_t *mp, >> case XFS_SBS_IFREE: >> case XFS_SBS_FDBLOCKS: >> if (!(mp->m_flags & XFS_MOUNT_NO_PERCPU_SB)) { >>- status = xfs_icsb_modify_counters_locked(mp, >>+ XFS_SB_UNLOCK(mp, s); >>+ status = xfs_icsb_modify_counters(mp, >> msbp->msb_field, >> msbp->msb_delta, >> rsvd); >>+ s = XFS_SB_LOCK(mp); >> break; >> } >> /* FALLTHROUGH */ >> >>Is it safe to be releasing the SB_LOCK? > > > Yes. > > >>Is it assumed that the >>superblock wont change while we process the list of xfs_mod_sb >>structures? > > > No. We are applying deltas - it doesn't matter if other deltas are > applied at the same time by other callers because in the end all > the deltas get applied and it adds up to the same thing. Okay. > > >>@@ -1515,11 +1517,12 @@ xfs_mod_incore_sb_batch(xfs_mount_t *mp, >> case XFS_SBS_IFREE: >> case XFS_SBS_FDBLOCKS: >> if (!(mp->m_flags & XFS_MOUNT_NO_PERCPU_SB)) >> { >>- status = >>- >>xfs_icsb_modify_counters_locked(mp, >>+ XFS_SB_UNLOCK(mp, s); >>+ status = xfs_icsb_modify_counters(mp, >> msbp->msb_field, >> -(msbp->msb_delta), >> rsvd); >>+ s = XFS_SB_LOCK(mp); >> break; >> } >> /* FALLTHROUGH */ >> >>Same as above. > > > Ditto ;) > > Thanks for looking at this, Lachlan. > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Fri Dec 1 12:13:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 12:13:17 -0800 (PST) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1KD8aG008420 for ; Fri, 1 Dec 2006 12:13:09 -0800 Received: from [134.15.160.29] (vpn-emea-sw-emea-160-29.emea.sgi.com [134.15.160.29]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kB1JsSqW70033103; Fri, 1 Dec 2006 11:54:29 -0800 (PST) Message-ID: <45708CA1.5090100@sgi.com> Date: Fri, 01 Dec 2006 20:12:17 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <20061201004112.GW37654165@melbourne.sgi.com> In-Reply-To: <20061201004112.GW37654165@melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9860 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs David Chinner wrote: > On Fri, Dec 01, 2006 at 09:38:11AM +1100, David Chinner wrote: > >>On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: >> >> >>>These changes wouldn't apply cleanly to tot (3 hunks failed in >>>xfs_mount.c) but I couldn't see why. >> >>Whitespace issue? Try setting: >> >>$ export QUILT_PATCH_OPTS="--ignore-whitespace" >> >>I'll apply the patch to a separate tree and see if I hit the same >>problem.... > > > I see the problem - the next patch I am going to send out for > review which is earlier in my series.... > > The growfs fix changes the delta parameter to xfs_icsb_modify_counters() > from int to int64_t, and that is why the hunks don't apply. > > The attached patch should apply (with a 6 line offset to most hunks). > That's even worse - now it loses track of which file it's patching. [lachlan@linux (2.6.x-xfs)2.6.x-xfs]$ patch -p1 -l -i ENOSPC.patch.eml patching file fs/xfs/xfs_mount.c Hunk #2 succeeded at 543 (offset 5 lines). Hunk #3 succeeded at 1485 (offset 6 lines). Hunk #4 succeeded at 1523 (offset 6 lines). Hunk #5 succeeded at 1736 (offset 6 lines). Hunk #6 succeeded at 1758 (offset 6 lines). Hunk #7 succeeded at 1794 (offset 6 lines). Hunk #8 succeeded at 1901 (offset 6 lines). Hunk #9 succeeded at 2021 (offset 6 lines). Hunk #10 succeeded at 2060 (offset 6 lines). Hunk #11 FAILED at 2087. 1 out of 11 hunks FAILED -- saving rejects to file fs/xfs/xfs_mount.c.rej missing header for unified diff at line 256 of patch can't find file to patch at input line 256 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- | break; | -------------------------- File to patch: Skip this patch? [y] Skipping patch. 3 out of 3 hunks ignored patching file fs/xfs/xfs_mount.h It seems to have a problem with line 256 of the patch: @@ -2081,7 +2121,7 @@ again: <---- line 256 lcounter = icsbp->icsb_ifree; lcounter += delta; if (unlikely(lcounter < 0)) - goto slow_path; + goto balance_counter; icsbp->icsb_ifree = lcounter; break; I can't see what's wrong. Don't sweat over it - it's not that important now that the review is done. I'll leave it to you to merge it with tot. Lachlan From owner-xfs@oss.sgi.com Fri Dec 1 12:29:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 12:29:40 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1KTUaG015432 for ; Fri, 1 Dec 2006 12:29:31 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB1KSfrX028519 for ; Fri, 1 Dec 2006 15:28:41 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB1KSfKk002215 for ; Fri, 1 Dec 2006 15:28:41 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB1KSdqn024592 for ; Fri, 1 Dec 2006 15:28:40 -0500 Message-ID: <45709075.7080906@sandeen.net> Date: Fri, 01 Dec 2006 14:28:37 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: on stack space.... Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9861 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs On the issue of stack space & where it goes in xfs... checkstack does not count function call arguments if you pass big-ish structures to functions things get skewed quickly the caller pushes the arguments just before the 'call' and also: btw one thing that helps modern gcc is to move variable declarations into the inner most {} scope possible does it really help? it'll allow it to share stack slots older gccs that was actually -worse- yes xfs was originally largely written that way how recent? 4.1 and later have this fixed lots of irix xfs was written this way IIRC, but I think things got moved out. Maybe it'd help to move them back in, for things like xfs_bmapi... although it's a -penalty- for older gcc's still I think. Anyway, just found that interesting, might help us get some of this under control without a huge amount of refactoring... -Eric From owner-xfs@oss.sgi.com Fri Dec 1 15:59:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 15:59:59 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB1NxoaG005694 for ; Fri, 1 Dec 2006 15:59:52 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GqIHU-0007MJ-RG; Sat, 02 Dec 2006 00:59:00 +0100 Date: Fri, 1 Dec 2006 23:59:08 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Iustin Pop cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs questions In-Reply-To: <20061201183034.GA20595@teal.hq.k1024.org> Message-ID: References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9862 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Fri, 1 Dec 2006, Iustin Pop wrote: > I don't understand how you took that conclusion. The explanations refer > to the default log size. I believe the original poster asked about the > performance advantage of *raising* the log size above the default values > for internal logs, I was under the assumption that the OP asked about altering the size of the log at all and the manpage only states a reason for *decreasing* the logsize. > and my impression is that metadata-intensive > workloads benefit from increasing the log size (however no hard numbers > are available). As no numbers are known to me either, I did not see a point in increasing the log, hence my statement. > A while back when mkfs.xfs had more conservative default value, bigger log > sizes indeed helped for big filesystems. As I've done a few benchmarks[0] for different filesystems lately I might find some time to play around with different fs tweaks... Christian. [0] http://nerdbynature.de/wp/?cat=4 -- BOFH excuse #353: Second-system effect. From owner-xfs@oss.sgi.com Fri Dec 1 16:26:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 16:26:45 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB20QaaG013055 for ; Fri, 1 Dec 2006 16:26:37 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GqIhO-0008CN-VT; Sat, 02 Dec 2006 01:25:47 +0100 Date: Sat, 2 Dec 2006 00:25:54 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Roger Heflin cc: xfs@oss.sgi.com Subject: Re: Issues with XFS on Sles9 sp2. In-Reply-To: <45704570.7020209@atipa.com> Message-ID: References: <45704570.7020209@atipa.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9863 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs On Fri, 1 Dec 2006, Roger Heflin wrote: > converting the machines to ext3 eliminates the issues. Under load > they were seeing 1-2 events per 24 hours on 100 machines. just to be sure: 1-2 machines out of 100 had a hanging XFS in 24h, right? (as opposed to "each of the 100 machines had 1-2 incidents in 24h" ;)) > They are using Sles9SP2, currently we cannot go to SP3 as there > are some other bad driver issues unrelated to XFS (the issue > preventing us from upgrading also appears to be in 2.6.16.x > kernel.org kernels so that is a more than just a SLES issue). So, you can't upgrade to a more current SuSE kernel, but you've already tried vanilla kernels? OK, you won't be able to upgrade to a kernel.org kernel because of the driver issues - but do the XFS hangs go away? Did it happen with earlier SuSE kernels too? > anywhere. The first type of machine to have the issue > and where the issue is alot more common has only 4GB > of ram, the second type of machine that has recently > starting also having the error has 32GB of ram. Shot in the dark: did you try to boot with the "mem=" option? You could try to boot with e.g. "mem=512M" and see if the problem has something to do with memory... Christian. -- BOFH excuse #228: That function is not currently supported, but Bill Gates assures us it will be featured in the next upgrade. From owner-xfs@oss.sgi.com Fri Dec 1 16:44:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 01 Dec 2006 16:44:45 -0800 (PST) Received: from mail.atipa.com (125.14.cm.sunflower.com [24.124.14.125]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB20iaaG014993 for ; Fri, 1 Dec 2006 16:44:37 -0800 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Issues with XFS on Sles9 sp2. Date: Fri, 1 Dec 2006 18:44:56 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issues with XFS on Sles9 sp2. thread-index: AccVqJNVOKYLHK14QIOTqkaBn5YODgAAC7dI References: <45704570.7020209@atipa.com> From: "Roger Heflin" To: "Christian Kujau" Cc: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 4199 X-archive-position: 9864 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rheflin@atipa.com Precedence: bulk X-list: xfs -----Original Message----- From: Christian Kujau [mailto:lists@nerdbynature.de] Sent: Fri 12/1/2006 6:25 PM To: Roger Heflin Cc: xfs@oss.sgi.com Subject: Re: Issues with XFS on Sles9 sp2. >On Fri, 1 Dec 2006, Roger Heflin wrote: >> converting the machines to ext3 eliminates the issues. Under load >> they were seeing 1-2 events per 24 hours on 100 machines. > >just to be sure: 1-2 machines out of 100 had a hanging XFS in 24h, >right? (as opposed to "each of the 100 machines had 1-2 incidents in >24h" ;)) 1-2 machines out of the 100 each 24 hours, different machines will fail the next day if they are under a similar load. >> They are using Sles9SP2, currently we cannot go to SP3 as there >> are some other bad driver issues unrelated to XFS (the issue >> preventing us from upgrading also appears to be in 2.6.16.x >> kernel.org kernels so that is a more than just a SLES issue). > >So, you can't upgrade to a more current SuSE kernel, but you've already >tried vanilla kernels? OK, you won't be able to upgrade to a kernel.org >kernel because of the driver issues - but do the XFS hangs go away? >Did it happen with earlier SuSE kernels too? I tested with the earlier vanilla kernels on only a couple of machines to see if the "other" problems was also in it, as if it was not I might be able to upgrade that specific part and the "other" problem was in the kernel.org kernel, so the new driver was unlikely fix anything so I don't have any data that would tell me if the problem XFS happens or not. We did not find the XFS issue in the testing stage (where the SP3 and kernel.org testing was done), we found the XFS issues in the early production phase. The customer can duplicate it, but those machines are connected by sneakernet, at a remote site. I also don't have similar data on earlier versions of sles as the SP1 setup only uses XFS on a limited number of file servers (no general usage) but on those file servers we have not seen any issues and have ran 4 machine like that for 1.5 years. Though if it were a out of kernel memory issue those machines may not be having that condition happen. The condition does not seem to happen at idle, the machines only lockup with a load on them, we never saw the issue at idle, or with well understood loads (HPL). >> anywhere. The first type of machine to have the issue >> and where the issue is alot more common has only 4GB >> of ram, the second type of machine that has recently >> starting also having the error has 32GB of ram. > >Shot in the dark: did you try to boot with the "mem=" option? >You could try to boot with e.g. "mem=512M" and see if the problem has >something to do with memory... I don't think it has to do with real memory, it may have to do with some resource that is in short supply at some time, like maybe a shortage of kernel memory at the wrong time, the machines have never been observed to fail under idle or under controlled loads (HPL) and we have significant runs times under both of those conditions (ie 20+ times the observed failure time) so far the machines have only failed under production loads, we have yet to be able to duplicate the failure under any test loads. The machines all appear to work correctly under tests like bonnie, and the machines are found with XFS locked up several hours later, so we don't really have a way of catching exactly what happened at the time of the event to cause it, non-xfs file systems still function, and the machine is still usable so long as one avoids the locked up XFS file systems, we only have 1 xfs file system on each machine so I don't know if a second xfs would also be locked up or not. Also these file systems are build on MD stripe arrays, and that may play some part in this. The ext3 filesystems are also build on the same md arrays and work just fine. We used XFS because we observed that ext3's write rates started to drop down significantly after a few minutes of sustained IO rates (much more than was expected from moving to the inner disk tracks), and XFS did not appear to suffer from this issue, so produced more predictable results. Roger [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat Dec 2 04:26:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 02 Dec 2006 04:26:27 -0800 (PST) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB2CQFaG002586 for ; Sat, 2 Dec 2006 04:26:17 -0800 Received: from teal.hq.k1024.org (84-75-116-60.dclient.hispeed.ch [84.75.116.60]) by astra.simleu.ro (Postfix) with ESMTP id 0DEB150; Sat, 2 Dec 2006 14:25:26 +0200 (EET) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 1B43440A0D2; Sat, 2 Dec 2006 12:15:47 +0100 (CET) Date: Sat, 2 Dec 2006 12:15:46 +0100 From: Iustin Pop To: Christian Kujau Cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs questions Message-ID: <20061202111546.GA18661@teal.hq.k1024.org> Mail-Followup-To: Christian Kujau , xfs@oss.sgi.com References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 9865 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs On Fri, Dec 01, 2006 at 11:59:08PM +0000, Christian Kujau wrote: > On Fri, 1 Dec 2006, Iustin Pop wrote: > >I don't understand how you took that conclusion. The explanations refer > >to the default log size. I believe the original poster asked about the > >performance advantage of *raising* the log size above the default values > >for internal logs, > > I was under the assumption that the OP asked about altering the size of > the log at all and the manpage only states a reason for *decreasing* the > logsize. Ah, I see. Sorry for the confusion. > >and my impression is that metadata-intensive > >workloads benefit from increasing the log size (however no hard numbers > >are available). > > As no numbers are known to me either, I did not see a point in > increasing the log, hence my statement. Hmm, I am pretty sure that it makes a difference, but only from personal experience, not from benchmarks. A while ago, mkfs.xfs used to make <8M logs even for big filesystems[0]. Nowadays it chooses a more sane value. > >A while back when mkfs.xfs had more conservative default value, bigger log > >sizes indeed helped for big filesystems. > > As I've done a few benchmarks[0] for different filesystems lately I > might find some time to play around with different fs tweaks... That would be interesting! [0] http://oss.sgi.com/archives/xfs/2002-04/msg00443.html and the corresponding thread, especially http://oss.sgi.com/archives/xfs/2002-04/msg00441.html Iustin From owner-xfs@oss.sgi.com Sun Dec 3 15:50:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Dec 2006 15:50:32 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB3NoKaG032621 for ; Sun, 3 Dec 2006 15:50:22 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04035; Mon, 4 Dec 2006 10:49:31 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB3NnT7Y52681469; Mon, 4 Dec 2006 10:49:30 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB3NnS9e52691638; Mon, 4 Dec 2006 10:49:28 +1100 (AEDT) Date: Mon, 4 Dec 2006 10:49:28 +1100 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC Message-ID: <20061203234928.GA37654165@melbourne.sgi.com> References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457080EA.1010807@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 9872 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1873 Lines: 49 On Fri, Dec 01, 2006 at 07:22:18PM +0000, Lachlan McIlroy wrote: > David Chinner wrote: > >On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: > >I think the slow path code is somewhat clearer with a separate > >mutex - it clearly documents the serialisation barrier that > >the slow path uses and allows us to do slow path checks on the > >per-cpu counters without needing the SB_LOCK. > > It's certainly an improvement over the original code. > > > > >It also means that in future, we can slowly remove the need for > >holding the SB_LOCK across the entire rebalance operation and only > >use it when referencing the global superblock fields during > >the rebalance. > > Sounds good. > > > > >If the need arises, it also means we can move to a mutex per counter > >so we can independently rebalance different types of counters at the > >same time (which we can't do right now). > > That seems so obvious - I'm surprised we can't do it now. Well, the reason I didn't go down this path in the first place was that typically only one type of counter would need rebalancing at a time (e.g. free blocks or free inodes, but not both at the same time). I tested this out on revenue2 with simultaneous creates and deletes of small files but could not cause contention on the single global lock under these loads. i also tried parallel writes of large files with creates and deletes, but hte create/delete was slowed sufficiently by the parallel writes that it once again didn't cause an issue. Hence it didn't seem to be an issue and a single lock simplified the initial implementation. What I'm thinking now is that it may become an issue with MDFS as acheivable create and delete rates should be much higher on one of these filesystems and then it may prove to be an issue. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Dec 3 16:06:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Dec 2006 16:06:44 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB406UaG002209 for ; Sun, 3 Dec 2006 16:06:34 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04381; Mon, 4 Dec 2006 11:05:37 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id DC19858FF58C; Mon, 4 Dec 2006 11:05:36 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 958790 - Fix xfsidbg.c compiler warnings on ia64 Message-Id: <20061204000536.DC19858FF58C@chook.melbourne.sgi.com> Date: Mon, 4 Dec 2006 11:05:36 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9873 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 557 Lines: 17 Fix xfsidbg.c compiler warnings on ia64 Date: Mon Dec 4 11:04:57 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27611a fs/xfs/xfsidbg.c - 1.310 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.310&r2=text&tr2=1.309&f=h - Cast variables with different definitions on 32/64 bit platforms to remove compiler warnings on 64 bit platforms. From owner-xfs@oss.sgi.com Sun Dec 3 16:26:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Dec 2006 16:26:24 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB40QAaG009199 for ; Sun, 3 Dec 2006 16:26:15 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04696; Mon, 4 Dec 2006 11:25:15 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 1994758FF58C; Mon, 4 Dec 2006 11:25:15 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 952227 - Severe lock contention in xfs_icsb_xxxx running Message-Id: <20061204002515.1994758FF58C@chook.melbourne.sgi.com> Date: Mon, 4 Dec 2006 11:25:15 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9874 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1945 Lines: 42 Reduction global superblock lock contention near ENOSPC. The existing per-cpu superblock counter code uses the global superblock spin lock when we approach ENOSPC for global synchronisation. On larger machines than this code was originally tested on this can still get catastrophic spinlock contention due increasing rebalance frequency near ENOSPC. By introducing a sleeping lock that is used to serialise balances and modifications near ENOSPC we prevent contention from needlessly from wasting the CPU time of potentially hundreds of CPUs. To reduce the number of balances occuring, we separate the need rebalance case from the slow allocate case. Now, a counter running dry will trigger a rebalance during which counters are disabled. Any thread that sees a disabled counter enters a different path where it waits on the new mutex. When it gets the new mutex, it checks if the counter is disabled. If the counter is disabled, then we _know_ that we have to use the global counter and lock and it is safe to do so immediately. Otherwise, we drop the mutex and go back to trying the per-cpu counters which we know were re-enabled. Date: Mon Dec 4 11:24:40 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27612a fs/xfs/xfs_mount.h - 1.228 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.228&r2=text&tr2=1.227&f=h - Add a new per-cpu counter synchronisation mutex. fs/xfs/xfs_mount.c - 1.388 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.388&r2=text&tr2=1.387&f=h - Reduce contention on the XFS_SB_LOCK() near ENOSPC by introducing a sleeping mutex for per-cpu superblock counter synchronisation and reworking the slow path to reduce counter rebalance frequency. From owner-xfs@oss.sgi.com Sun Dec 3 17:36:20 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 03 Dec 2006 17:36:27 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB41aHaG017481 for ; Sun, 3 Dec 2006 17:36:19 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06205; Mon, 4 Dec 2006 12:35:25 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB41ZN7Y29871513; Mon, 4 Dec 2006 12:35:24 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB41ZKLX52644943; Mon, 4 Dec 2006 12:35:20 +1100 (AEDT) Date: Mon, 4 Dec 2006 12:35:20 +1100 From: David Chinner To: Stephen Pollei Cc: Mike Mattie , "linux-kernel @ vger. kernel. org" , xfs@oss.sgi.com Subject: Re: "BUG: held lock freed!" lock validator tripped by kswapd & xfs Message-ID: <20061204013520.GI44411608@melbourne.sgi.com> References: <20061201095349.2a92c997@reforged> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 9875 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1693 Lines: 41 On Fri, Dec 01, 2006 at 02:34:42PM -0800, Stephen Pollei wrote: > On 12/1/06, Mike Mattie wrote: > > >In an attempt to debug another kernel issue I turned on the lock validator > >and > >managed to generate this report. > > > >As a side note the first attempt to boot with the lock validator failed > >with > >a message indicating I had exceeded MAX_LOCK_DEPTH. To get this trace > >I patched sched.h: MAX_LOCK_DEPTH to 60. > > > >Dec 1 08:35:41 reforged [ 3052.513931] ========================= > >Dec 1 08:35:41 reforged [ 3052.513937] [ BUG: held lock freed! ] > >Dec 1 08:35:41 reforged [ 3052.513939] ------------------------- > >Dec 1 08:35:41 reforged [ 3052.513943] kswapd0/183 is freeing memory > >c3458000-c3458fff, with a lock still held there! Dec 1 08:35:41 > >reforged [ 3052.513947] (&(&ip->i_iolock)->mr_lock){....}, at: > >[] xfs_ilock+0x20/0x75 Dec 1 08:35:41 reforged > >[ 3052.513959] 28 locks held by kswapd0/183: Dec 1 08:35:41 reforged > >[ 3052.513961] #0: (&(&ip->i_iolock)->mr_lock){....}, at: > >[] xfs_ilock+0x20/0x75 Dec 1 08:35:41 reforged > >[ 3052.513968] #1: (&(&ip->i_lock)->mr_lock){....}, at: [] > >xfs_ilock+0x52/0x75 Dec 1 08:35:41 reforged [ 3052.513975] > > seems to alternate between same two locks. But both c0222289 and > c02222bb are not between the page(oxfff=4095 or about 4k) which kswapd > is trying to get rid of. > I think this trace is on crack somehow. IIRC, lockdep doesn't understand the xfs inode locks yet. We've got a patch to fix most of this, but I don't think it's been merged. Cheers, Dave -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 4 03:34:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Dec 2006 03:35:06 -0800 (PST) Received: from mail.lst.de (verein.lst.de [213.95.11.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB4BYvaG002796 for ; Mon, 4 Dec 2006 03:34:59 -0800 Received: from verein.lst.de (localhost [127.0.0.1]) by mail.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id kB4BY6si011799 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 4 Dec 2006 12:34:06 +0100 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id kB4BY6UV011797; Mon, 4 Dec 2006 12:34:06 +0100 Date: Mon, 4 Dec 2006 12:34:06 +0100 From: Christoph Hellwig To: David Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] remove v_number Message-ID: <20061204113406.GC11074@lst.de> References: <20061129154729.GC6400@lst.de> <20061130003050.GG33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061130003050.GG33919298@melbourne.sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-archive-position: 9876 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Content-Length: 1234 Lines: 25 On Thu, Nov 30, 2006 at 11:30:50AM +1100, David Chinner wrote: > On Wed, Nov 29, 2006 at 04:47:29PM +0100, Christoph Hellwig wrote: > > v_number is unused except for the naming some locks (which is a > > functionality totally unused by Linux), so remove it and assorted > > crap. Besides saving two words in struct vnode this also gets rid > > of a spinlock per inode allocation. > > Hmm - given that I've just used the v_number in post-mortem analysis > of a nasty bug to correlate the sequence of events during a series > of mkdir operations (i.e. transactions in the incore log buffers, > the resulting xfs_inodes and some screwed up dentries) that lead to > a BUG_ON being tripped in d_instantiate. > > So, while it appears to be unused, it is _very_ useful for > determining the SOE that has occurred in certain types of problems. > > FWIW, while analysing this crash dump a couple of days ago I was > wishing that dentries had an equivalent sequence number because > there is no way to tell what dentry was supposed to be related to > what inode after it got screwed up... Putting in sequence counting is trivial using kprobes. Will you put in this patch after I write you a kprobes modules to do the sequence numbering? From owner-xfs@oss.sgi.com Mon Dec 4 08:20:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Dec 2006 08:20:49 -0800 (PST) Received: from mcvs4.priv.usm.edu (smtp.usm.edu [131.95.82.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB4GKdaG027896 for ; Mon, 4 Dec 2006 08:20:41 -0800 Received: from anakin ([131.95.175.215]) by mcvs4.priv.usm.edu (8.12.11/8.12.11) with ESMTP id kB4GVdwV031915 for ; Mon, 4 Dec 2006 10:31:39 -0600 Message-Id: <200612041631.kB4GVdwV031915@mcvs4.priv.usm.edu> From: "Robert Johnson" To: Subject: Xfs errors: Date: Mon, 4 Dec 2006 09:47:46 -0600 Organization: iTech- TIU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccXu4sQQSvOIm7HRK+EshHA17F+IA== X-archive-position: 9878 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: robert.e.johnson@usm.edu Precedence: bulk X-list: xfs Content-Length: 897 Lines: 24 I have just installed and configured a xfs file system on Redhat AS4 server, running on IBM eServer 366 platform. The file system was carved out of our EMC SAN, with Qlogic HBA dual port fiber channel cards. The error message is as follows: Dec 4 09:43:11 mail kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 4 09:43:14 mail kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 4 09:43:15 mail kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x250) Dec 4 09:44:44 mail kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x2d0) -------------------------------------------- R.E. Johnson, Linux Systems Administrator Disaster Recovery Administrator University of Southern Mississippi iTech, Technology Infrastructure Unit robert.e.johnson@usm.edu ------------------------------------------- From owner-xfs@oss.sgi.com Mon Dec 4 09:54:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Dec 2006 09:54:08 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB4Hs0aG008383 for ; Mon, 4 Dec 2006 09:54:01 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB4HrATx029341; Mon, 4 Dec 2006 12:53:10 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB4HrAU5001576; Mon, 4 Dec 2006 12:53:10 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB4Hr755009834; Mon, 4 Dec 2006 12:53:09 -0500 Message-ID: <45746082.2090403@sandeen.net> Date: Mon, 04 Dec 2006 11:53:06 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Robert Johnson CC: xfs@oss.sgi.com Subject: Re: Xfs errors: References: <200612041631.kB4GVdwV031915@mcvs4.priv.usm.edu> In-Reply-To: <200612041631.kB4GVdwV031915@mcvs4.priv.usm.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9879 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 796 Lines: 22 Robert Johnson wrote: > I have just installed and configured a xfs file system on Redhat AS4 server, RHEL4 doesn't support xfs ;-) > running on IBM eServer 366 platform. The file system was carved out of our > EMC SAN, with Qlogic HBA dual port fiber channel cards. The error message is > as follows: > > Dec 4 09:43:11 mail kernel: XFS: possible memory allocation deadlock in > kmem_alloc (mode:0x250) > Dec 4 09:43:14 mail kernel: XFS: possible memory allocation deadlock in > kmem_alloc (mode:0x250) > Dec 4 09:43:15 mail kernel: XFS: possible memory allocation deadlock in > kmem_alloc (mode:0x250) > Dec 4 09:44:44 mail kernel: XFS: possible memory allocation deadlock in > kmem_alloc (mode:0x2d0) You might have highly fragmented files, and xfs_fsr might help with this... -Eric From owner-xfs@oss.sgi.com Mon Dec 4 13:57:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 04 Dec 2006 13:57:51 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB4LvdaG014737 for ; Mon, 4 Dec 2006 13:57:42 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA14131; Tue, 5 Dec 2006 08:56:40 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB4Lud7Y53620000; Tue, 5 Dec 2006 08:56:39 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB4LuaYI53617980; Tue, 5 Dec 2006 08:56:36 +1100 (AEDT) Date: Tue, 5 Dec 2006 08:56:36 +1100 From: David Chinner To: Christoph Hellwig Cc: David Chinner , xfs@oss.sgi.com Subject: Re: [PATCH] remove v_number Message-ID: <20061204215636.GM33919298@melbourne.sgi.com> References: <20061129154729.GC6400@lst.de> <20061130003050.GG33919298@melbourne.sgi.com> <20061204113406.GC11074@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061204113406.GC11074@lst.de> User-Agent: Mutt/1.4.2.1i X-archive-position: 9881 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2169 Lines: 53 On Mon, Dec 04, 2006 at 12:34:06PM +0100, Christoph Hellwig wrote: > On Thu, Nov 30, 2006 at 11:30:50AM +1100, David Chinner wrote: > > On Wed, Nov 29, 2006 at 04:47:29PM +0100, Christoph Hellwig wrote: > > > v_number is unused except for the naming some locks (which is a > > > functionality totally unused by Linux), so remove it and assorted > > > crap. Besides saving two words in struct vnode this also gets rid > > > of a spinlock per inode allocation. > > > > Hmm - given that I've just used the v_number in post-mortem analysis > > of a nasty bug to correlate the sequence of events during a series > > of mkdir operations (i.e. transactions in the incore log buffers, > > the resulting xfs_inodes and some screwed up dentries) that lead to > > a BUG_ON being tripped in d_instantiate. > > > > So, while it appears to be unused, it is _very_ useful for > > determining the SOE that has occurred in certain types of problems. > > > > FWIW, while analysing this crash dump a couple of days ago I was > > wishing that dentries had an equivalent sequence number because > > there is no way to tell what dentry was supposed to be related to > > what inode after it got screwed up... > > Putting in sequence counting is trivial using kprobes. Never used kprobes - I'll take your word that it's easy.... > Will you put > in this patch after I write you a kprobes modules to do the sequence > numbering? I wasn't NACKing your patch - I was making the point that this apparently unused code does have some useful, non-obvious, redeeming features. Pardon my lack of kprobes knowledge, but what is the point of removing this code if we have to then go and add kprobes instrumentation to every XFS installation we support to provide the same information? Where does the kprobes data get kept? In the kernel, or partially in kernel and in userspace? How would you correlate the sequence number and the vnode from the crash dump? How much extra runtime memory does it use? I'm not saying no, Christoph - I'm just trying to understand the implications of what you are suggesting.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 5 04:00:25 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 04:00:31 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5C0NaG020519 for ; Tue, 5 Dec 2006 04:00:24 -0800 Received: from [194.173.12.131] (helo=[172.25.16.7]) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1GrYl51Bwu-0003BV; Tue, 05 Dec 2006 12:46:48 +0100 Message-ID: <45755C26.2080505@gmx.net> Date: Tue, 05 Dec 2006 12:46:46 +0100 From: Klaus Strebel User-Agent: Thunderbird 3.0a1 (Windows/20061204) MIME-Version: 1.0 To: David Chinner CC: Lachlan McIlroy , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> <20061203234928.GA37654165@melbourne.sgi.com> In-Reply-To: <20061203234928.GA37654165@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Provags-ID: kundenserver.de abuse@kundenserver.de login:8a7df7300d3d15a4f701302fdde7adf9 X-archive-position: 9883 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: klaus.strebel@gmx.net Precedence: bulk X-list: xfs Content-Length: 2409 Lines: 62 David Chinner wrote: > On Fri, Dec 01, 2006 at 07:22:18PM +0000, Lachlan McIlroy wrote: >> David Chinner wrote: >>> On Thu, Nov 30, 2006 at 06:03:40PM +0000, Lachlan McIlroy wrote: >>> I think the slow path code is somewhat clearer with a separate >>> mutex - it clearly documents the serialisation barrier that >>> the slow path uses and allows us to do slow path checks on the >>> per-cpu counters without needing the SB_LOCK. >> It's certainly an improvement over the original code. >> >>> It also means that in future, we can slowly remove the need for >>> holding the SB_LOCK across the entire rebalance operation and only >>> use it when referencing the global superblock fields during >>> the rebalance. >> Sounds good. >> >>> If the need arises, it also means we can move to a mutex per counter >>> so we can independently rebalance different types of counters at the >>> same time (which we can't do right now). >> That seems so obvious - I'm surprised we can't do it now. > > Well, the reason I didn't go down this path in the first place > was that typically only one type of counter would need rebalancing > at a time (e.g. free blocks or free inodes, but not both at the > same time). I tested this out on revenue2 with simultaneous creates > and deletes of small files but could not cause contention on the > single global lock under these loads. i also tried parallel > writes of large files with creates and deletes, but hte create/delete > was slowed sufficiently by the parallel writes that it once again > didn't cause an issue. > > Hence it didn't seem to be an issue and a single lock simplified > the initial implementation. What I'm thinking now is that it may > become an issue with MDFS as acheivable create and delete rates > should be much higher on one of these filesystems and then it may > prove to be an issue. > > Cheers, > > Dave. Hi guys, just updated my CVS copy from oss.sgi.com ( the linux-2.6-xfs ) and tried to compile ... but your patch failes to compile if HAVE_PERCPU_SB is #ifndef'd :-(, the m_icsb_mutex is not in the struct see xfs_mount.h. Make oldconfig didn't show HAVE_PERCPU_SB as option for .config, looks like nobody tested on a single processor config ?? Ciao Klaus -- Mit freundlichen Grüssen / best regards Klaus Strebel, Dipl.-Inform. (FH), mailto:klaus.strebel@gmx.net /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \ From owner-xfs@oss.sgi.com Tue Dec 5 10:15:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 10:15:26 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5IFHaG010040 for ; Tue, 5 Dec 2006 10:15:19 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GreN1-0003Cf-0v; Tue, 05 Dec 2006 18:46:19 +0100 Date: Tue, 5 Dec 2006 17:46:15 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: Iustin Pop cc: xfs@oss.sgi.com, jasmin@pacifica.ch Subject: Re: mkfs.xfs questions In-Reply-To: <20061202111546.GA18661@teal.hq.k1024.org> Message-ID: References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9884 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: christian@nerdbynature.de Precedence: bulk X-list: xfs Content-Length: 553 Lines: 17 On Sat, 2 Dec 2006, Iustin Pop wrote: > Hmm, I am pretty sure that it makes a difference, but only from personal > experience, not from benchmarks. A while ago, mkfs.xfs used to make <8M > logs even for big filesystems[0]. Nowadays it chooses a more sane value. I could not stand my own curiosity, so here it is: http://nerdbynature.de/wp/?cat=4 I think I'll repeat the benchmarks with bigger test sizes. The testscript can easily be adjusted to test more options/values. Christian. -- BOFH excuse #248: Too much radiation coming from the soil. From owner-xfs@oss.sgi.com Tue Dec 5 11:39:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 11:39:14 -0800 (PST) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5Jd4aG020686 for ; Tue, 5 Dec 2006 11:39:06 -0800 Received: from teal.hq.k1024.org (84-75-117-178.dclient.hispeed.ch [84.75.117.178]) by astra.simleu.ro (Postfix) with ESMTP id EB35159; Tue, 5 Dec 2006 21:38:13 +0200 (EET) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 2D66E40A0B2; Tue, 5 Dec 2006 19:44:56 +0100 (CET) Date: Tue, 5 Dec 2006 19:44:56 +0100 From: Iustin Pop To: Christian Kujau Cc: xfs@oss.sgi.com, jasmin@pacifica.ch Subject: Re: mkfs.xfs questions Message-ID: <20061205184456.GA12989@teal.hq.k1024.org> Mail-Followup-To: Christian Kujau , xfs@oss.sgi.com, jasmin@pacifica.ch References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 9885 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs Content-Length: 728 Lines: 18 On Tue, Dec 05, 2006 at 05:46:15PM +0000, Christian Kujau wrote: > On Sat, 2 Dec 2006, Iustin Pop wrote: > >Hmm, I am pretty sure that it makes a difference, but only from personal > >experience, not from benchmarks. A while ago, mkfs.xfs used to make <8M > >logs even for big filesystems[0]. Nowadays it chooses a more sane value. > > I could not stand my own curiosity, so here it is: > http://nerdbynature.de/wp/?cat=4 > > I think I'll repeat the benchmarks with bigger test sizes. The > testscript can easily be adjusted to test more options/values. Hmm, I see tests with 32M logs and 64M logs. Try running the file creation/deletion test also with 4M, 8M, 16M, and then I'll think there will be a difference. Iustin From owner-xfs@oss.sgi.com Tue Dec 5 13:28:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 13:28:12 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB5LS0aG009034 for ; Tue, 5 Dec 2006 13:28:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA02123; Wed, 6 Dec 2006 08:26:59 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB5LQt7Y54218361; Wed, 6 Dec 2006 08:26:56 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB5LQn7g54725915; Wed, 6 Dec 2006 08:26:49 +1100 (AEDT) Date: Wed, 6 Dec 2006 08:26:49 +1100 From: David Chinner To: Christian Kujau Cc: Iustin Pop , xfs@oss.sgi.com, jasmin@pacifica.ch Subject: Re: mkfs.xfs questions Message-ID: <20061205212649.GV44411608@melbourne.sgi.com> References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 9886 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1269 Lines: 37 On Tue, Dec 05, 2006 at 05:46:15PM +0000, Christian Kujau wrote: > On Sat, 2 Dec 2006, Iustin Pop wrote: > >Hmm, I am pretty sure that it makes a difference, but only from personal > >experience, not from benchmarks. A while ago, mkfs.xfs used to make <8M > >logs even for big filesystems[0]. Nowadays it chooses a more sane value. > > I could not stand my own curiosity, so here it is: > http://nerdbynature.de/wp/?cat=4 One line summary: "The results however are a bit boring and I for one have no reason to tweak these options for a desktop machine." For that data set size you tested. However you might find a difference if your tests actually write the data back to disk because a lot of the tests are running out of cache. > I think I'll repeat the benchmarks with bigger test sizes. The > testscript can easily be adjusted to test more options/values. I think you need to to have any hope of demonstrating a difference in performance from the mkfs/mount options. Typically, you need to be writing/reading files at least 2x the size of memory and create/delete a fileset of at least 1,000,000 files to really determine differences in performance from these parameters... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Tue Dec 5 13:56:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 13:56:11 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB5Lu1aG011740 for ; Tue, 5 Dec 2006 13:56:03 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA03187; Wed, 6 Dec 2006 08:55:08 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB5Lt67Y54707816; Wed, 6 Dec 2006 08:55:07 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB5Lt4u154716683; Wed, 6 Dec 2006 08:55:04 +1100 (AEDT) Date: Wed, 6 Dec 2006 08:55:04 +1100 From: David Chinner To: Klaus Strebel Cc: David Chinner , Lachlan McIlroy , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC Message-ID: <20061205215503.GW44411608@melbourne.sgi.com> References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> <20061203234928.GA37654165@melbourne.sgi.com> <45755C26.2080505@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45755C26.2080505@gmx.net> User-Agent: Mutt/1.4.2.1i X-archive-position: 9887 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 4748 Lines: 162 On Tue, Dec 05, 2006 at 12:46:46PM +0100, Klaus Strebel wrote: > Hi guys, > > just updated my CVS copy from oss.sgi.com ( the linux-2.6-xfs ) and > tried to compile ... but your patch failes to compile if HAVE_PERCPU_SB > is #ifndef'd :-(, the m_icsb_mutex is not in the struct see xfs_mount.h. > Make oldconfig didn't show HAVE_PERCPU_SB as option for .config, looks > like nobody tested on a single processor config ?? Sorry - my bad. The code did not change for UP, so I didn't think to test it. The patch below abstracts the icsb_mutex so that it doesn't get directly referenced by code outside the per-cpu counter code. Builds with and without HAVE_PERCPU_SB defined. I'll run a test cycle on it and get it fixed up. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_mount.c | 23 ++++++++++++----------- fs/xfs/xfs_mount.h | 20 ++++++++++++++++++++ 2 files changed, 32 insertions(+), 11 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.c 2006-12-04 11:33:54.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.c 2006-12-06 08:43:25.389157507 +1100 @@ -536,11 +536,11 @@ xfs_readsb(xfs_mount_t *mp, int flags) ASSERT(XFS_BUF_VALUSEMA(bp) <= 0); } - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); xfs_icsb_balance_counter(mp, XFS_SBS_ICOUNT, 0, 0); xfs_icsb_balance_counter(mp, XFS_SBS_IFREE, 0, 0); xfs_icsb_balance_counter(mp, XFS_SBS_FDBLOCKS, 0, 0); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); mp->m_sb_bp = bp; xfs_buf_relse(bp); @@ -1726,17 +1726,17 @@ xfs_icsb_cpu_notify( memset(cntp, 0, sizeof(xfs_icsb_cnts_t)); break; case CPU_ONLINE: - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); xfs_icsb_balance_counter(mp, XFS_SBS_ICOUNT, 0, 0); xfs_icsb_balance_counter(mp, XFS_SBS_IFREE, 0, 0); xfs_icsb_balance_counter(mp, XFS_SBS_FDBLOCKS, 0, 0); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); break; case CPU_DEAD: /* Disable all the counters, then fold the dead cpu's * count into the total on the global superblock and * re-enable the counters. */ - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); s = XFS_SB_LOCK(mp); xfs_icsb_disable_counter(mp, XFS_SBS_ICOUNT); xfs_icsb_disable_counter(mp, XFS_SBS_IFREE); @@ -1755,7 +1755,7 @@ xfs_icsb_cpu_notify( xfs_icsb_balance_counter(mp, XFS_SBS_FDBLOCKS, XFS_ICSB_SB_LOCKED, 0); XFS_SB_UNLOCK(mp, s); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); break; } @@ -1803,6 +1803,7 @@ xfs_icsb_destroy_counters( unregister_hotcpu_notifier(&mp->m_icsb_notifier); free_percpu(mp->m_sb_cnts); } + mutex_destroy(&mp->m_icsb_mutex); } STATIC_INLINE void @@ -2146,7 +2147,7 @@ slow_path: * the superblock lock. We still need to hold the superblock * lock, however, when we modify the global structures. */ - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); /* * Now running atomically. @@ -2155,7 +2156,7 @@ slow_path: * Drop the lock and try again in the fast path.... */ if (!(xfs_icsb_counter_disabled(mp, field))) { - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); goto again; } @@ -2182,7 +2183,7 @@ slow_path: */ if (ret != ENOSPC) xfs_icsb_balance_counter(mp, field, 0, 0); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); return ret; balance_counter: @@ -2195,7 +2196,7 @@ balance_counter: * do more balances than strictly necessary but it is not * the common slowpath case. */ - mutex_lock(&mp->m_icsb_mutex); + xfs_icsb_lock(mp); /* * running atomically. @@ -2206,7 +2207,7 @@ balance_counter: * another balance operation being required. */ xfs_icsb_balance_counter(mp, field, 0, delta); - mutex_unlock(&mp->m_icsb_mutex); + xfs_icsb_unlock(mp); goto again; } Index: 2.6.x-xfs-new/fs/xfs/xfs_mount.h =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_mount.h 2006-12-04 11:33:56.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_mount.h 2006-12-06 08:43:18.630046128 +1100 @@ -576,6 +576,26 @@ xfs_daddr_to_agbno(struct xfs_mount *mp, } /* + * Per-cpu superblock locking functions + */ +#ifdef HAVE_PERCPU_SB +STATIC_INLINE void +xfs_icsb_lock(xfs_mount_t *mp) +{ + mutex_lock(&mp->m_icsb_mutex); +} + +STATIC_INLINE void +xfs_icsb_unlock(xfs_mount_t *mp) +{ + mutex_unlock(&mp->m_icsb_mutex); +} +#else +#define xfs_icsb_lock(mp) +#define xfs_icsb_unlock(mp) +#endif + +/* * This structure is for use by the xfs_mod_incore_sb_batch() routine. * xfs_growfs can specify a few fields which are more than int limit */ From owner-xfs@oss.sgi.com Tue Dec 5 14:29:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 14:29:16 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5MT7aG015152 for ; Tue, 5 Dec 2006 14:29:08 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Grily-00076E-L7; Tue, 05 Dec 2006 23:28:22 +0100 Date: Tue, 5 Dec 2006 22:28:18 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: David Chinner cc: Iustin Pop , xfs@oss.sgi.com Subject: Re: mkfs.xfs questions In-Reply-To: <20061205212649.GV44411608@melbourne.sgi.com> Message-ID: References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> <20061205212649.GV44411608@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9888 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs Content-Length: 1032 Lines: 31 On Wed, 6 Dec 2006, David Chinner wrote: > For that data set size you tested. However you might find a > difference if your tests actually write the data back to disk > because a lot of the tests are running out of cache. Ha, thanks for reminding me! Now I remember why all my other tests were done with 2GB of data, having 1GB of RAM ;) > Typically, you need to be writing/reading files at least 2x the > size of memory I started a test with 4GB of data (bonnie++ -s 4096m) an hour ago... > and create/delete a fileset of at least 1,000,000 > files to really determine differences in performance from hm, that would be 'bonnie++ -n 1000' instead of the "-n 100" I'm testing right now. Thanks for the hints, David! If you/someone know any better/closer-to-real-usage benchmarks, please let me know. I'm testing with bonnie++ because it I don't know any better. is iozone any good? is tiobench still worth to try? Christian. -- BOFH excuse #208: Your mail is being routed through Germany ... and they're censoring us. From owner-xfs@oss.sgi.com Tue Dec 5 15:07:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 15:07:34 -0800 (PST) Received: from page.mel.office.aconex.com (eth2333.vic.adsl.internode.on.net [150.101.159.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB5N7PaG018926 for ; Tue, 5 Dec 2006 15:07:28 -0800 Received: from localhost (page.mel.aconex.com [127.0.0.1]) by page.mel.office.aconex.com (Postfix) with ESMTP id 38D9453420D; Wed, 6 Dec 2006 10:06:23 +1100 (EST) Received: from page.mel.office.aconex.com ([127.0.0.1]) by localhost (mail.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22276-01-99; Wed, 6 Dec 2006 10:06:21 +1100 (EST) Received: from edge (unknown [192.168.0.246]) by page.mel.office.aconex.com (Postfix) with ESMTP id D7A3F534205; Wed, 6 Dec 2006 10:06:21 +1100 (EST) Subject: Recent changes in xfsprogs From: Nathan Scott Reply-To: nscott@aconex.com To: bnaujok@sgi.com Cc: xfs@oss.sgi.com Content-Type: text/plain Organization: Aconex Date: Wed, 06 Dec 2006 10:06:10 +1100 Message-Id: <1165359970.1281.51.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9889 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 936 Lines: 29 Yo Barry, xfsprogs/doc/CHANGES - Rename include/list.h to xfs_list.h so that other applications do not accidentally use it. What was the problem here? This doesnt sound like the right fix - there should be no applications outside of the XFS userspace that use libxfs.h - thats what is for (exactly this reason, preventing namespace collision, by reducing all the XFS internals being exposed). Also, there seems to be lots of checkin mail not making it out to oss.sgi.com (let alone review mail), making it difficult for people to keep up to date with changes (and keep distros, like Debian, uptodate) ... could y'all make some effort to keep us "on the outside" in the loop? Oh, noone is updating oss.sgi.com/projects/xfs/{news,index}.html with recent changes either - seems like progress has come to a halt to those of us no longer in the secret cabal, anyway ;) ... just FYI. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Dec 5 17:50:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 17:50:32 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB61oLaG009568 for ; Tue, 5 Dec 2006 17:50:23 -0800 Received: from [134.14.55.18] (dhcp18.melbourne.sgi.com [134.14.55.18]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10744; Wed, 6 Dec 2006 12:49:23 +1100 Message-ID: <457621A2.7000605@melbourne.sgi.com> Date: Wed, 06 Dec 2006 12:49:22 +1100 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: nscott@aconex.com CC: bnaujok@sgi.com, xfs@oss.sgi.com Subject: Re: Recent changes in xfsprogs References: <1165359970.1281.51.camel@edge> In-Reply-To: <1165359970.1281.51.camel@edge> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9890 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1698 Lines: 52 Nathan, Nathan Scott wrote: > Yo Barry, > > xfsprogs/doc/CHANGES > > - Rename include/list.h to xfs_list.h so that other applications > do not accidentally use it. > > What was the problem here? This doesnt sound like the right fix - > there should be no applications outside of the XFS userspace that > use libxfs.h - thats what is for (exactly this reason, > preventing namespace collision, by reducing all the XFS internals > being exposed). > A classic problem with cpp is that it is possible for someone else to introduce a header that breaks your build. By introducing a header called list.h, a very common name, we have exposed products whose build may not have strictly doing the right thing (adding /usr/include/xfs to their include path) to pulling in this file rather than the one they intended. So strictly speaking XFS was doing nothing wrong, but its a simple change for us to make to be more friendly. The application that had this problem has also been fixed to use . > Also, there seems to be lots of checkin mail not making it out to > oss.sgi.com (let alone review mail), making it difficult for people > to keep up to date with changes (and keep distros, like Debian, > uptodate) ... could y'all make some effort to keep us "on the > outside" in the loop? > True, not everything has been escaping of late. > Oh, noone is updating oss.sgi.com/projects/xfs/{news,index}.html > with recent changes either - seems like progress has come to a > halt to those of us no longer in the secret cabal, anyway ;) ... > just FYI. > Its now on my list of things to do. David -- David Chatterton XFS Engineering Manager SGI Australia From owner-xfs@oss.sgi.com Tue Dec 5 18:09:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 05 Dec 2006 18:09:44 -0800 (PST) Received: from page.mel.office.aconex.com (eth2333.vic.adsl.internode.on.net [150.101.159.28]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB629aaG012288 for ; Tue, 5 Dec 2006 18:09:37 -0800 Received: from localhost (page.mel.aconex.com [127.0.0.1]) by page.mel.office.aconex.com (Postfix) with ESMTP id 9A891534117; Wed, 6 Dec 2006 13:08:34 +1100 (EST) Received: from page.mel.office.aconex.com ([127.0.0.1]) by localhost (mail.aconex.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01371-01-78; Wed, 6 Dec 2006 13:08:32 +1100 (EST) Received: from edge (unknown [192.168.0.246]) by page.mel.office.aconex.com (Postfix) with ESMTP id A0EEC534197; Wed, 6 Dec 2006 13:08:32 +1100 (EST) Subject: Re: Recent changes in xfsprogs From: Nathan Scott Reply-To: nscott@aconex.com To: chatz@melbourne.sgi.com Cc: bnaujok@sgi.com, xfs@oss.sgi.com In-Reply-To: <457621A2.7000605@melbourne.sgi.com> References: <1165359970.1281.51.camel@edge> <457621A2.7000605@melbourne.sgi.com> Content-Type: text/plain Organization: Aconex Date: Wed, 06 Dec 2006 13:08:22 +1100 Message-Id: <1165370902.1281.72.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9891 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 1639 Lines: 44 On Wed, 2006-12-06 at 12:49 +1100, David Chatterton wrote: > ... > A classic problem with cpp is that it is possible for someone else to > introduce a header that breaks your build. Heh, its a poor tradesman who blames his tools. :) > By introducing a header > called list.h, a very common name, we have exposed products whose build > may not have strictly doing the right thing (adding /usr/include/xfs to > their include path) to pulling in this file rather than the one they > intended. Well, clearly they're doing the wrong thing. We've now introduced a half-baked scheme where one random header is inconsistent with the rest, because of some other broken application. That's dopey. The convention there now is such that its easy to tell what include/ files have kernel counterparts (the xfs_* prefixed ones), and the rest are generically named (list.h, cache.h, parent.h, paths.h, linux.h, etc). This change now makes list.h sit in no-mans-land... please revert it back, since the app is fixed anyway (you are also, of course, ignoring the flip side of your own argument, which is that other equally broken apps could be using , which moved and hence broke their builds). You can't win by pandering to broken 3rd party applications... best you can do is keep the XFS stuff sane and internally consistent. > > Oh, noone is updating oss.sgi.com/projects/xfs/{news,index}.html > > with recent changes either - seems like progress has come to a > > halt to those of us no longer in the secret cabal, anyway ;) ... > > just FYI. > > > > Its now on my list of things to do. > Great - thanks! cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Dec 6 00:44:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 00:44:48 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB68idaG006283 for ; Wed, 6 Dec 2006 00:44:40 -0800 Received: from [134.15.160.6] (vpn-emea-sw-emea-160-6.emea.sgi.com [134.15.160.6]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kB68hmbj62947159; Wed, 6 Dec 2006 00:43:49 -0800 (PST) Message-ID: <457682C3.6000802@sgi.com> Date: Wed, 06 Dec 2006 08:43:47 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: Klaus Strebel , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> <20061203234928.GA37654165@melbourne.sgi.com> <45755C26.2080505@gmx.net> <20061205215503.GW44411608@melbourne.sgi.com> In-Reply-To: <20061205215503.GW44411608@melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9892 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 1080 Lines: 36 David Chinner wrote: > On Tue, Dec 05, 2006 at 12:46:46PM +0100, Klaus Strebel wrote: > >>Hi guys, >> >>just updated my CVS copy from oss.sgi.com ( the linux-2.6-xfs ) and >>tried to compile ... but your patch failes to compile if HAVE_PERCPU_SB >>is #ifndef'd :-(, the m_icsb_mutex is not in the struct see xfs_mount.h. >>Make oldconfig didn't show HAVE_PERCPU_SB as option for .config, looks >>like nobody tested on a single processor config ?? > > > Sorry - my bad. The code did not change for UP, so I didn't think to > test it. The patch below abstracts the icsb_mutex so that it > doesn't get directly referenced by code outside the per-cpu counter > code. Builds with and without HAVE_PERCPU_SB defined. > > I'll run a test cycle on it and get it fixed up. > > Cheers, > > Dave. @@ -1803,6 +1803,7 @@ xfs_icsb_destroy_counters( unregister_hotcpu_notifier(&mp->m_icsb_notifier); free_percpu(mp->m_sb_cnts); } + mutex_destroy(&mp->m_icsb_mutex); } Do you need to abstract the call to mutex_destroy too? The rest of the change looks good. Lachlan From owner-xfs@oss.sgi.com Wed Dec 6 07:58:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 07:58:51 -0800 (PST) Received: from mail.g-house.de (ns2.g-housing.de [81.169.133.75]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB6FwfaG024879 for ; Wed, 6 Dec 2006 07:58:44 -0800 Received: from [82.41.152.154] (helo=82-41-152-154.cable.ubr01.linl.blueyonder.co.uk) by mail.g-house.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1Grz9g-0007JM-Mh for xfs@oss.sgi.com; Wed, 06 Dec 2006 16:57:56 +0100 Date: Wed, 6 Dec 2006 15:57:55 +0000 (GMT) From: Christian Kujau X-X-Sender: evil@sheep.housecafe.de To: xfs@oss.sgi.com Subject: Re: mkfs.xfs questions In-Reply-To: Message-ID: References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> <20061205212649.GV44411608@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 9894 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@nerdbynature.de Precedence: bulk X-list: xfs Content-Length: 295 Lines: 14 On Tue, 5 Dec 2006, Christian Kujau wrote: > I started a test with 4GB of data (bonnie++ -s 4096m) an hour ago... took 16hrs to complete, wow: http://nerdbynature.de/bench/amd64/2.6.19-git7_xfs.2/ http://nerdbynature.de/wp/?cat=4 C. -- BOFH excuse #293: You must've hit the wrong any key. From owner-xfs@oss.sgi.com Wed Dec 6 14:10:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 14:10:21 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB6MA8aG001475 for ; Wed, 6 Dec 2006 14:10:12 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB6M8F5x005672; Wed, 6 Dec 2006 17:08:15 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB6M8F1u028093; Wed, 6 Dec 2006 17:08:15 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB6M8Dsp010360; Wed, 6 Dec 2006 17:08:14 -0500 Message-ID: <45773F4D.4040800@sandeen.net> Date: Wed, 06 Dec 2006 16:08:13 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: nscott@aconex.com CC: bnaujok@sgi.com, xfs@oss.sgi.com Subject: Re: Recent changes in xfsprogs References: <1165359970.1281.51.camel@edge> In-Reply-To: <1165359970.1281.51.camel@edge> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9897 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 336 Lines: 12 Nathan Scott wrote: > Also, there seems to be lots of checkin mail not making it out to > oss.sgi.com (let alone review mail), making it difficult for people > to keep up to date with changes (and keep distros, like Debian, > uptodate) ... could y'all make some effort to keep us "on the > outside" in the loop? here here! :) -Eric From owner-xfs@oss.sgi.com Wed Dec 6 15:56:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 15:56:15 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB6Nu5aG014198 for ; Wed, 6 Dec 2006 15:56:07 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA05425; Tue, 7 Nov 2006 17:32:26 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 5E2B458FA27C; Tue, 7 Nov 2006 17:32:26 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 956832 - Fix xfs_iunpin() sets I_DIRTY_SYNC after clear_inode() Message-Id: <20061107063226.5E2B458FA27C@chook.melbourne.sgi.com> Date: Tue, 7 Nov 2006 17:32:26 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9899 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2398 Lines: 47 Prevent a deadlock when xfslogd unpins inodes. The previous fixes for the use after free in xfs_iunpin left a nasty log deadlock when xfslogd unpinned the inode and dropped the last reference to the inode. the ->clear_inode() method can issue transactions, and if the log was full, the transaction could push on the log and get stuck trying to push the inode it was currently unpinning. To fix this, we provide xfs_iunpin a guarantee that it will always have a valid xfs_inode <-> linux inode link or a particular flag will be set on the inode. We then use log forces during lookup to ensure transactions are completed before we recycle the inode. This ensures that xfs_iunpin will never use the linux inode after it is being freed, and any lookup on an inode on the reclaim list will wait until it is safe to attach a new linux inode to the xfs inode. Date: Tue Nov 7 17:31:17 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: stripathi@agami.com,t-nagano@ah.jp.nec.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27359a fs/xfs/xfs_vnodeops.c - 1.687 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.687&r2=text&tr2=1.686&f=h - Set the reclaimable flag before we break the xfs inode - linux inode link so that xfs_iunpin doesn't have to deal with linux-inode use-after-free conditions during inode reclaim. fs/xfs/xfs_iget.c - 1.224 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.224&r2=text&tr2=1.223&f=h - If we find a reclaimable inode, make sure it is not pinned before we reuse it so we don't get inode unpinning running incorrectly on a new linux inode. Also ensure that we don't remove unlinked reclaimable inodes from the reclaim list which would cause them to leak. fs/xfs/xfs_inode.c - 1.454 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.454&r2=text&tr2=1.453&f=h - Remove the igrab/iput form xfs_iunpin and provide it with a guarantee that either the inode will be marked reclaimable or the xfs inode - linux inode link will be intact. This fixes a deadlock that calling iput() from the xfslogd can trigger while also providing us a reliable method for avoiding use-after-free of the linux inode. From owner-xfs@oss.sgi.com Wed Dec 6 16:46:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 16:47:00 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB70kmaG023128 for ; Wed, 6 Dec 2006 16:46:51 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA04190; Wed, 22 Nov 2006 18:01:18 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 9C5FB58CF865; Wed, 22 Nov 2006 18:01:18 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 958469 - Quiet mounts on XFS aren't Message-Id: <20061122070118.9C5FB58CF865@chook.melbourne.sgi.com> Date: Wed, 22 Nov 2006 18:01:18 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9900 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 598 Lines: 19 Make quiet mounts quiet The XFS quiet mount logic was inverted making quiet mounts noisy and vice versa. Fix it. Date: Wed Nov 22 18:00:45 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: sandeen@sandeen.net,tes@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27520a fs/xfs/xfs_error.h - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h - Fix xfs_fs_mount_cmn_err() quiet flag logic inversion. From owner-xfs@oss.sgi.com Wed Dec 6 16:47:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 16:47:15 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB70l2aG023174 for ; Wed, 6 Dec 2006 16:47:05 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04824; Tue, 7 Nov 2006 17:01:43 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 0CFA558FA27C; Tue, 7 Nov 2006 17:01:42 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 956832 - xfs_iunpin() sets I_DIRTY_SYNC after clear_inode() Message-Id: <20061107060143.0CFA558FA27C@chook.melbourne.sgi.com> Date: Tue, 7 Nov 2006 17:01:42 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9901 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1288 Lines: 32 Clean up i_flags and i_flags_lock handling. Date: Tue Nov 7 17:00:11 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: nscott@aconex.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27358a fs/xfs/xfs_vnodeops.c - 1.686 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.686&r2=text&tr2=1.685&f=h - Use prepackaged i_flags handling functions. fs/xfs/xfs_iget.c - 1.223 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_iget.c.diff?r1=text&tr1=1.223&r2=text&tr2=1.222&f=h - Use prepackaged i_flags handling functions. fs/xfs/xfs_inode.c - 1.453 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.453&r2=text&tr2=1.452&f=h - Use prepackaged i_flags handling functions. fs/xfs/xfs_inode.h - 1.217 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.h.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h - define common i_flags handling functions. fs/xfs/linux-2.6/xfs_super.c - 1.373 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.373&r2=text&tr2=1.372&f=h - Use prepackaged i_flags handling functions. From owner-xfs@oss.sgi.com Wed Dec 6 17:24:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 17:24:45 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB71OaaG028414 for ; Wed, 6 Dec 2006 17:24:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24668; Thu, 7 Dec 2006 12:23:41 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB71Nd7Y55668941; Thu, 7 Dec 2006 12:23:40 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB71Ncjq55707662; Thu, 7 Dec 2006 12:23:38 +1100 (AEDT) Date: Thu, 7 Dec 2006 12:23:38 +1100 From: David Chinner To: Christian Kujau Cc: xfs@oss.sgi.com Subject: Re: mkfs.xfs questions Message-ID: <20061207012338.GK44411608@melbourne.sgi.com> References: <20061129174553.e0ef3465.jasmin@pacifica.ch> <20061201183034.GA20595@teal.hq.k1024.org> <20061202111546.GA18661@teal.hq.k1024.org> <20061205212649.GV44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 9902 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 748 Lines: 26 On Wed, Dec 06, 2006 at 03:57:55PM +0000, Christian Kujau wrote: > On Tue, 5 Dec 2006, Christian Kujau wrote: > >I started a test with 4GB of data (bonnie++ -s 4096m) an hour ago... > > took 16hrs to complete, wow: > > http://nerdbynature.de/bench/amd64/2.6.19-git7_xfs.2/ > http://nerdbynature.de/wp/?cat=4 You should try version 2 logs and larger log buffer sizes. Also - external log I/O is not cached, so throughput to the log is determined by the hardware. If the external log is slow, it may be worse than an internal log in terms of performance. Larger log buffers (v2 logs) should improve performance for these tests on both internal and external logs. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 6 19:56:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 06 Dec 2006 19:56:57 -0800 (PST) Received: from mail.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB73umaG012980 for ; Wed, 6 Dec 2006 19:56:50 -0800 X-ASG-Debug-ID: 1165458838-15a700010000-NocioJ X-Barracuda-URL: http://cuda.aconex.com:8000/cgi-bin/mark.cgi X-Barracuda-Connect: unknown[192.168.3.1] X-Barracuda-Start-Time: 1165458838 Received: from postoffice.aconex.com (unknown [192.168.3.1]) by mail.aconex.com (Spam Firewall) with ESMTP id 1D80928D; Thu, 7 Dec 2006 13:33:58 +1100 (EST) Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id A7E17AAC18E; Thu, 7 Dec 2006 13:29:23 +1100 (EST) X-ASG-Orig-Subj: Re: [RFC][PATCH] Secure Deletion and Trash-Bin Support for Ext4 Subject: Re: [RFC][PATCH] Secure Deletion and Trash-Bin Support for Ext4 From: Nathan Scott Reply-To: nscott@aconex.com To: David Chinner Cc: Nikolai Joukov , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, xfs@oss.sgi.com In-Reply-To: <20061206091100.GA33919298@melbourne.sgi.com> References: <20061204235042.GS33919298@melbourne.sgi.com> <20061206091100.GA33919298@melbourne.sgi.com> Content-Type: text/plain Organization: Aconex Date: Thu, 07 Dec 2006 09:16:31 +1100 Message-Id: <1165443391.1281.135.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at aconex.com X-archive-position: 9903 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 1033 Lines: 30 On Wed, 2006-12-06 at 20:11 +1100, David Chinner wrote: > ... > If all we need to add to XFS is support for those flags, then XFS > support would be trivial to add. > > Oh, damn. I take that back. We're almost out of flag space in the on > disk inode - these two flags would use the last 2 flag bits so this > may require an on disk inode format change in XFS. This will be > a little more complex than I first thought, ... It should be OK - you can do it without an inode version revision if you take a second 16 bits for "di_flags2" from here... xfs_dinode_core { ... __uint8_t di_pad[8]; /* unused, zeroed space */ Its guaranteed zeroed initially (i.e. all flags unset) and the XFS get/set flags APIs are 32 bits, so you should be OK there. Also, it may also be possible to reclaim di_onlink at some point (maybe now, since 16 bits would be good here) if mkfs.xfs is changed to always create v2 inodes (dynamic conversion ATM IIRC)... not 100% sure though, needs more code analysis. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Dec 7 09:38:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 09:38:52 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7HciaG027043 for ; Thu, 7 Dec 2006 09:38:45 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120712174462:372 ; Thu, 7 Dec 2006 12:17:44 -0500 Message-ID: <45784E71.4080605@falconstor.com> Date: Thu, 07 Dec 2006 12:25:05 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Eric Sandeen Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> In-Reply-To: <4560AB84.9060200@sandeen.net> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 12:17:44 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 12:38:46 PM, Serialize complete at 12/07/2006 12:38:46 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9905 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 1326 Lines: 41 Eric Sandeen wrote: > http://sandeen.net/rhel4_xfs/kernel-module-xfs-2.6.9-42.0.2.EL-0.2-1.src.rpm > > > rpmbuild --rebuild --target i686 > kernel-module-xfs-2.6.9-42.0.2.EL-0.2-1.src.rpm > > will build against the currently running kernel, or > > rpmbuild --rebuild --target i686 --define "kernel_topdir > /lib/modules/2.6.9-42.0.2.EL/build" > kernel-module-xfs-2.6.9-42.0.2.EL-0.2-1.src.rpm > > will build against what is defined in kernel_topdir > > you need matching kernel & kernel-devel rpms installed to build. > I built this for RHELAS4U2 x86_64 with the 2.6.9-22.ELsmp kernel. I did enable the xfs_direct_io_locking.patch (see inside kernel-module-xfs.spec for details). However, I run into issues with xfs_freeze as it often locks up when I try to freeze a file system where there is I/O activity. Sometimes it happen on the first xfs_freeze invocation to freeze the file system, other times I have to unfreeze and then it happens on the second time I freeze. xfs_freeze never returns when this happens. Looks like xfs_io get stuck --see partial output from `ps auxf`: strace -ff -o freeze.txt xfs_freeze -f /mnt/xfs \_ /bin/sh -f /usr/sbin/xfs_freeze -f /mnt/xfs \_ /usr/sbin/xfs_io -r -p xfs_freeze -x -c freeze /mnt/xfs Anyone else encountering this issue? -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Thu Dec 7 09:53:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 09:53:51 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7HrdaG028993 for ; Thu, 7 Dec 2006 09:53:45 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB7HqDGF029031; Thu, 7 Dec 2006 12:52:13 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB7HqDCZ019047; Thu, 7 Dec 2006 12:52:13 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB7HqB4h003146; Thu, 7 Dec 2006 12:52:12 -0500 Message-ID: <457854CB.5030507@sandeen.net> Date: Thu, 07 Dec 2006 11:52:11 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: geir.myrestrand@falconstor.com CC: xfs@oss.sgi.com Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> In-Reply-To: <45784E71.4080605@falconstor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9906 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 809 Lines: 24 Geir A. Myrestrand wrote: > However, I run into issues with xfs_freeze as it often locks up when I > try to freeze a file system where there is I/O activity. Sometimes it > happen on the first xfs_freeze invocation to freeze the file system, > other times I have to unfreeze and then it happens on the second time I > freeze. xfs_freeze never returns when this happens. > > Looks like xfs_io get stuck --see partial output from `ps auxf`: > > strace -ff -o freeze.txt xfs_freeze -f /mnt/xfs > \_ /bin/sh -f /usr/sbin/xfs_freeze -f /mnt/xfs > \_ /usr/sbin/xfs_io -r -p xfs_freeze -x -c freeze /mnt/xfs > > Anyone else encountering this issue? > Did you have this problem on the previous version? You might do sysrq-t (echo t > /proc/sysrq-trigger) and see where the thread is stuck. -Eric From owner-xfs@oss.sgi.com Thu Dec 7 10:19:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 10:19:41 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7IJTaG032200 for ; Thu, 7 Dec 2006 10:19:33 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120713101078:386 ; Thu, 7 Dec 2006 13:10:10 -0500 Message-ID: <45785ABC.20208@falconstor.com> Date: Thu, 07 Dec 2006 13:17:32 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Eric Sandeen Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> In-Reply-To: <457854CB.5030507@sandeen.net> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 01:10:11 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 01:19:35 PM, Serialize complete at 12/07/2006 01:19:35 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9907 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 12238 Lines: 271 Eric Sandeen wrote: > Geir A. Myrestrand wrote: > >> However, I run into issues with xfs_freeze as it often locks up when I >> try to freeze a file system where there is I/O activity. Sometimes it >> happen on the first xfs_freeze invocation to freeze the file system, >> other times I have to unfreeze and then it happens on the second time I >> freeze. xfs_freeze never returns when this happens. >> >> Looks like xfs_io get stuck --see partial output from `ps auxf`: >> >> strace -ff -o freeze.txt xfs_freeze -f /mnt/xfs >> \_ /bin/sh -f /usr/sbin/xfs_freeze -f /mnt/xfs >> \_ /usr/sbin/xfs_io -r -p xfs_freeze -x -c freeze /mnt/xfs >> >> Anyone else encountering this issue? >> > > Did you have this problem on the previous version? > > You might do sysrq-t (echo t > /proc/sysrq-trigger) and see where the > thread is stuck. I reproduced it and dumped the task list. The user-mode XFS processes were: root 2816 0.0 0.1 2812 628 pts/3 S+ 12:58 0:00 | \_ strace -ff -o freeze.txt xfs_freeze -f /mnt/xfs root 2847 0.0 0.2 52752 1048 pts/3 T+ 12:58 0:00 | \_ /bin/sh -f /usr/sbin/xfs_freeze -f /mnt/xfs root 2891 0.0 0.1 49976 600 pts/3 D+ 12:58 0:00 | \_ /usr/sbin/xfs_io -r -p xfs_freeze -x -c freeze /mnt/xfs My I/O generating processes were: root 3832 1.9 0.2 59644 1376 pts/1 S+ 12:57 0:17 | \_ /usr/bin/perl ./test.pl root 2992 0.0 0.0 49912 404 pts/1 D+ 12:58 0:00 | \_ touch 857 Here are some relevant information from /var/log/messages (I stuck in a divider when I pasted in sections that weren't just right after the previous section): pdflush D ffffffff8014a190 0 48 6 50 47 (L-TLB) 000001001f99dcb8 0000000000000046 0000000080134722 ffffffffa0054a51 000000001f99dc30 0000000000000000 000001001fa2e310 0000000000000000 000001001f9737f0 00000000000000d9 Call Trace:{:ext3:ext3_ordered_writepage+0} {:xfs:xlog_state_sync_all+456} {:xfs:pagebuf_rele+54} {keventd_create_kthread+0} {__down+147} {default_wake_function+0} {__down_failed+53} {:xfs:xfs_sync+0} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+37} {:xfs:xfs_syncsub+2507} {keventd_create_kthread+0} {__down_trylock+68} {keventd_create_kthread+0} {:xfs:linvfs_write_super+33} {sync_supers+167} {wb_kupdate+36} {pdflush+323} {wb_kupdate+0} {pdflush+0} {kthread+200} {child_rip+8} {keventd_create_kthread+0} {kthread+0} {child_rip+0} ---------------------------------------------------------------------------- xfs S 0000000000000006 0 2723 1 2742 2697 (NOTLB) 00000100156e9d78 0000000000000002 00000100156e9d98 0000010000000074 000001001eb87880 000001001eb878f0 000000d000000000 0000000100000246 00000100154cc030 0000000000005f88 Call Trace:{__mod_timer+293} {schedule_timeout+244} {process_timeout+0} {do_select+939} {__pollwait+0} {sys_select+820} {dnotify_parent+34} {system_call+126} ---------------------------------------------------------------------------- xfslogd/0 S ffffffffa01f54b0 0 3818 6 3819 1981 (L-TLB) 00000100104e5e68 0000000000000046 0000000000000283 0000010011a268e0 ffffffffa01f54b0 0000000000000246 ffffffff80303cc1 00000000a01bb7a8 0000010011d377f0 000000000000023e Call Trace:{:xfs:pagebuf_iodone_work+0} {__up_wakeup+53} {:xfs:pagebuf_iodone_work+0} {worker_thread+226} {default_wake_function+0} {default_wake_function+0} {keventd_create_kthread+0} {worker_thread+0} {keventd_create_kthread+0} {kthread+200} {child_rip+8} {keventd_create_kthread+0} {kthread+0} {child_rip+0} xfslogd/1 S ffffffffa01f54b0 0 3819 6 3820 3818 (L-TLB) 00000100105d7e68 0000000000000046 0000000000000287 ffffffffa01e2960 000001000e48eb20 000001000e48eb20 0000010012d7e260 0000000100000246 000001001053f7f0 000000000000022f Call Trace:{:xfs:xfs_trans_delete_ail+45} {:xfs:pagebuf_iodone_work+0} {worker_thread+226} {default_wake_function+0} {default_wake_function+0} {keventd_create_kthread+0} {worker_thread+0} {keventd_create_kthread+0} {kthread+200} {child_rip+8} {keventd_create_kthread+0} {kthread+0} {child_rip+0} xfsdatad/0 S 00000100164aa9c0 0 3820 6 3821 3819 (L-TLB) 00000100104e1e68 0000000000000046 000000000032a7bd 000000190000006a 000001001053e7f0 000000000000006a 0000010001707840 0000000000187397 000001001053f030 0000000000000d8a Call Trace:{keventd_create_kthread+0} {worker_thread+0} {worker_thread+226} {default_wake_function+0} {default_wake_function+0} {keventd_create_kthread+0} {worker_thread+0} {keventd_create_kthread+0} {kthread+200} {child_rip+8} {keventd_create_kthread+0} {kthread+0} {child_rip+0} xfsdatad/1 S 00000100164aaa40 0 3821 6 3820 (L-TLB) 00000100104e3e68 0000000000000046 000000260000000a 0000001900000074 000001001f9bd030 0000000000000074 000001000170f840 000000010032ba4b 000001001053e7f0 0000000000000b24 Call Trace:{keventd_create_kthread+0} {worker_thread+0} {worker_thread+226} {default_wake_function+0} {default_wake_function+0} {keventd_create_kthread+0} {worker_thread+0} {keventd_create_kthread+0} {kthread+200} {child_rip+8} {keventd_create_kthread+0} {kthread+0} {child_rip+0} xfsbufd S 000000010027d0c0 0 3822 1 3827 3815 (L-TLB) 00000100111fdea8 0000000000000046 ffffffff803d9920 0000001900000073 000001001f9bd030 0000000000000073 0000010001707840 0000000080138348 000001001053e030 000000000000019b Call Trace:{__mod_timer+293} {schedule_timeout+244} {process_timeout+0} {:xfs:xfsbufd+172} {child_rip+8} {flat_send_IPI_mask+0} {:xfs:xfsbufd+0} {child_rip+0} xfssyncd S ffffffffa01f36b9 0 3827 1 3822 (L-TLB) 0000010011f0fea8 0000000000000046 ffffffffa01f36b9 0000000000000202 ffffffff8010f459 00000100126e2d40 000001001d5e3980 0000000100000000 000001001e4dd7f0 00000000000025eb Call Trace:{:xfs:linvfs_fill_super+0} {__down_trylock+68} {__mod_timer+293} {:xfs:linvfs_fill_super+0} {schedule_timeout+244} {process_timeout+0} {:xfs:xfssyncd+120} {child_rip+8} {:xfs:linvfs_fill_super+0} {dummy_d_instantiate+0} {:xfs:xfssyncd+0} {child_rip+0} ---------------------------------------------------------------------------- xfs_freeze t 00000000006c51e0 0 2847 2816 2891 (NOTLB) 00000100074d7e78 0000000000000002 0000010015654030 00000100111fec40 0000000000000206 ffffffff801410a6 0000000000000011 0000000000040004 0000010015654030 0000000000001a97 Call Trace:{do_notify_parent_cldstop+243} {ptrace_stop+315} {ptrace_notify+139} {syscall_trace+37} {syscall_trace_enter+43} {tracesys+113} xfs_io D 00000100146af380 0 2891 2816 2847 (NOTLB) 00000100075c9af8 0000000000000002 000001000a415b80 0000000000000064 000000000007d000 ffffffff802499ca ffffffff80134722 00000001075c9a90 000001000e83f7f0 0000000001a7ca67 Call Trace:{generic_make_request+355} {autoremove_wake_function+0} {__down+147} {default_wake_function+0} {__down_failed+53} {:xfs:xfs_bdstrat_cb+0} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_flush_buftarg+213} {:xfs:xfs_quiesce_fs+69} {:xfs:linvfs_sync_super+65} {freeze_bdev+215} {:xfs:xfs_ioctl+5161} {find_get_page+65} {filemap_nopage+378} {finish_task_switch+55} {thread_return+42} {ptrace_stop+386} {ptrace_notify+167} {:xfs:linvfs_ioctl+112} {sys_ioctl+853} {tracesys+209} touch D 0000000000239000 0 2992 3832 (NOTLB) 0000010008dd76e8 0000000000000006 0000000000000001 0000000000000001 0000000000000016 ffffffff80131931 0000000100000000 0000000000000003 000001001ed54030 00000000000078de Call Trace:{try_to_wake_up+734} {:xfs:_pagebuf_find+327} {__down+147} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:_pagebuf_find+358} {:xfs:xfs_buf_get_flags+100} {:xfs:xfs_bmap_search_extents+92} {:xfs:xfs_buf_read_flags+16} {:xfs:xfs_trans_read_buf+428} {:xfs:xfs_da_do_buf+984} {:xfs:xfs_da_read_buf+21} {:xfs:xfs_da_node_lookup_int+145} {:xfs:xfs_da_node_lookup_int+145} {:xfs:xfs_dir2_node_addname+83} {:xfs:xfs_ichgtime+93} {wake_up_inode+6} {:xfs:xfs_bmap_last_offset+179} {:xfs:xfs_dir2_createname+283} {:xfs:xfs_create+992} {dummy_inode_permission+0} {:xfs:linvfs_mknod+453} {:xfs:xfs_da_brelse+116} {:xfs:xfs_dir2_node_lookup+170} {:xfs:xfs_dir2_lookup+248} {vfs_create+214} {open_namei+430} {filp_open+39} {strncpy_from_user+74} {get_unused_fd+230} {sys_open+57} {system_call+126} -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Thu Dec 7 10:21:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 10:21:17 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7IL9aG032631 for ; Thu, 7 Dec 2006 10:21:10 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120713122189:387 ; Thu, 7 Dec 2006 13:12:21 -0500 Message-ID: <45785B3F.7010505@falconstor.com> Date: Thu, 07 Dec 2006 13:19:43 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Eric Sandeen Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> In-Reply-To: <457854CB.5030507@sandeen.net> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 01:12:22 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 01:21:12 PM, Serialize complete at 12/07/2006 01:21:12 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9908 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 181 Lines: 10 Eric Sandeen wrote: > Did you have this problem on the previous version? Not sure if this occur with the older XFS modules, because I haven't tested it. -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Thu Dec 7 12:53:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 12:53:08 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7KqxaG023431 for ; Thu, 7 Dec 2006 12:53:02 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120715441016:439 ; Thu, 7 Dec 2006 15:44:10 -0500 Message-ID: <45787ED4.5070801@falconstor.com> Date: Thu, 07 Dec 2006 15:51:32 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Eric Sandeen Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> In-Reply-To: <457854CB.5030507@sandeen.net> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 03:44:10 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 03:53:04 PM, Serialize complete at 12/07/2006 03:53:04 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9909 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 557 Lines: 18 Eric Sandeen wrote: > Geir A. Myrestrand wrote: > >> However, I run into issues with xfs_freeze as it often locks up when I >> try to freeze a file system where there is I/O activity. Sometimes it >> happen on the first xfs_freeze invocation to freeze the file system, >> other times I have to unfreeze and then it happens on the second time I >> freeze. xfs_freeze never returns when this happens. >> > > Did you have this problem on the previous version? I just tested with the old version, and I run into the same issue. -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Thu Dec 7 13:12:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 13:12:54 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7LCiaG026069 for ; Thu, 7 Dec 2006 13:12:46 -0800 Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id 4DE83AAC1A8; Fri, 8 Dec 2006 08:07:14 +1100 (EST) Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms From: Nathan Scott Reply-To: nscott@aconex.com To: geir.myrestrand@falconstor.com Cc: xfs@oss.sgi.com, Eric Sandeen In-Reply-To: <45787ED4.5070801@falconstor.com> References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> Content-Type: text/plain Organization: Aconex Date: Fri, 08 Dec 2006 08:11:46 +1100 Message-Id: <1165525906.30459.25.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9910 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 1031 Lines: 28 On Thu, 2006-12-07 at 15:51 -0500, Geir A. Myrestrand wrote: > Eric Sandeen wrote: > > Geir A. Myrestrand wrote: > > > >> However, I run into issues with xfs_freeze as it often locks up when I > >> try to freeze a file system where there is I/O activity. Sometimes it > >> happen on the first xfs_freeze invocation to freeze the file system, > >> other times I have to unfreeze and then it happens on the second time I > >> freeze. xfs_freeze never returns when this happens. > >> > > > > Did you have this problem on the previous version? > > I just tested with the old version, and I run into the same issue. > Does it happen with mainline (current) kernels? This is ringing some distant bells, something to do with an atomic_inc being in the wrong spot in [_]xfs_trans_alloc ... or maybe a wrong call to xfs_trans_alloc instead of the '_' prefixed version - details are murky now though. I do remember fixing ... something in here, a few months back, that fix may not be in Eric's codebase yet. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Dec 7 13:36:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 13:36:44 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7LaWaG029410 for ; Thu, 7 Dec 2006 13:36:34 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120716281276:458 ; Thu, 7 Dec 2006 16:28:12 -0500 Message-ID: <45788927.4030207@falconstor.com> Date: Thu, 07 Dec 2006 16:35:35 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: nscott@aconex.com, Eric Sandeen Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> In-Reply-To: <1165525906.30459.25.camel@edge> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 04:28:12 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 04:36:36 PM, Serialize complete at 12/07/2006 04:36:36 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9911 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 1109 Lines: 28 Nathan Scott wrote: > Does it happen with mainline (current) kernels? This is ringing some > distant bells, something to do with an atomic_inc being in the wrong > spot in [_]xfs_trans_alloc ... or maybe a wrong call to xfs_trans_alloc > instead of the '_' prefixed version - details are murky now though. I > do remember fixing ... something in here, a few months back, that fix > may not be in Eric's codebase yet. > > cheers. I've only tried this on RHELAS4 with the kernel shipped with Update 2. I have not tried to update the kernel, or install Update 4 or whatever is current now. My kernel is 2.6.9-22.ELsmp. It wouldn't be easy for me to switch to a newer kernel, because it is not just a matter of my machine --we have a product built for this particular configuration. Switching to a new kernel would reset our QA efforts. If this may be fixed in the XFS modules on the other hand, then it would be awesome if we could get it resolved with an updated XFS package for RHEL4. I would be more than willing to put in an extra effort and work with anyone on this. -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Thu Dec 7 13:41:29 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 13:41:39 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7LfQaG030384 for ; Thu, 7 Dec 2006 13:41:29 -0800 Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id 8BAFCAAC1C1; Fri, 8 Dec 2006 08:35:55 +1100 (EST) Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms From: Nathan Scott Reply-To: nscott@aconex.com To: geir.myrestrand@falconstor.com Cc: xfs@oss.sgi.com, Eric Sandeen In-Reply-To: <45788927.4030207@falconstor.com> References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> Content-Type: text/plain Organization: Aconex Date: Fri, 08 Dec 2006 08:40:28 +1100 Message-Id: <1165527628.30459.31.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9912 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 575 Lines: 17 On Thu, 2006-12-07 at 16:35 -0500, Geir A. Myrestrand wrote: > > It wouldn't be easy for me to switch to a newer kernel, because it is > not just a matter of my machine --we have a product built for this > particular configuration. Switching to a new kernel would reset our > QA efforts. You misunderstood me I think - I didn't suggest switching kernels, just that you test out the latest. If its OK, then its relatively easy to search for a change that fixed it. If its not OK, then theres a bug in mainline which should get some attention too. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Dec 7 13:52:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 13:52:46 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7LqbaG031797 for ; Thu, 7 Dec 2006 13:52:38 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120716435131:462 ; Thu, 7 Dec 2006 16:43:51 -0500 Message-ID: <45788CD1.9010509@falconstor.com> Date: Thu, 07 Dec 2006 16:51:13 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: nscott@aconex.com CC: xfs@oss.sgi.com, Eric Sandeen Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> <1165527628.30459.31.camel@edge> In-Reply-To: <1165527628.30459.31.camel@edge> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 04:43:51 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 04:52:40 PM, Serialize complete at 12/07/2006 04:52:40 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9913 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 745 Lines: 19 Nathan Scott wrote: > On Thu, 2006-12-07 at 16:35 -0500, Geir A. Myrestrand wrote: >> It wouldn't be easy for me to switch to a newer kernel, because it is >> not just a matter of my machine --we have a product built for this >> particular configuration. Switching to a new kernel would reset our >> QA efforts. > > You misunderstood me I think - I didn't suggest switching kernels, just > that you test out the latest. If its OK, then its relatively easy to > search for a change that fixed it. If its not OK, then theres a bug in > mainline which should get some attention too. Sorry Nathan, but I'm not sure I understand what you refer to with "test out the latest" --are you referring to the kernel or XFS? -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Thu Dec 7 14:07:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 14:07:51 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7M7haG001138 for ; Thu, 7 Dec 2006 14:07:44 -0800 Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id 80381AAC1C3; Fri, 8 Dec 2006 09:02:12 +1100 (EST) Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms From: Nathan Scott Reply-To: nscott@aconex.com To: geir.myrestrand@falconstor.com Cc: xfs@oss.sgi.com, Eric Sandeen In-Reply-To: <45788CD1.9010509@falconstor.com> References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> <1165527628.30459.31.camel@edge> <45788CD1.9010509@falconstor.com> Content-Type: text/plain Organization: Aconex Date: Fri, 08 Dec 2006 09:06:45 +1100 Message-Id: <1165529205.30459.36.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9914 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 315 Lines: 12 On Thu, 2006-12-07 at 16:51 -0500, Geir A. Myrestrand wrote: > Sorry Nathan, but I'm not sure I understand what you refer to with > "test out the latest" --are you referring to the kernel or XFS? Yes. :) Current mainline kernels, or CVS from oss.sgi.com would have this fix I'm thinking of. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Dec 7 14:17:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 14:17:50 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7MHfaG002653 for ; Thu, 7 Dec 2006 14:17:43 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120717090460:475 ; Thu, 7 Dec 2006 17:09:04 -0500 Message-ID: <457892BB.1000203@falconstor.com> Date: Thu, 07 Dec 2006 17:16:27 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: nscott@aconex.com, Eric Sandeen Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> <1165527628.30459.31.camel@edge> <45788CD1.9010509@falconstor.com> <1165529205.30459.36.camel@edge> In-Reply-To: <1165529205.30459.36.camel@edge> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 05:09:04 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 05:17:44 PM, Serialize complete at 12/07/2006 05:17:44 PM Content-Type: multipart/mixed; boundary="------------070406040306080604080504" X-archive-position: 9915 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 1469 Lines: 52 This is a multi-part message in MIME format. --------------070406040306080604080504 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed Nathan Scott wrote: > On Thu, 2006-12-07 at 16:51 -0500, Geir A. Myrestrand wrote: >> Sorry Nathan, but I'm not sure I understand what you refer to with >> "test out the latest" --are you referring to the kernel or XFS? > > Yes. :) Current mainline kernels, or CVS from oss.sgi.com would > have this fix I'm thinking of. Thanks for the "clarification"... ;-) I'll try to update the XFS code first, hopefully it won't break too many of the patches Eric had in his source RPM...but I will try to correct them if they fail to apply cleanly... I'll keep you posted. -- Geir A. Myrestrand --------------070406040306080604080504 Content-Transfer-Encoding: 7bit Content-Type: text/x-vcard; charset=utf-8; name="geir.myrestrand.vcf" Content-Disposition: attachment; filename="geir.myrestrand.vcf" begin:vcard fn:Geir A. Myrestrand n:Myrestrand;Geir A. org:FalconStor Software, Inc. adr:Suite 2S01;;2 Huntington Quadrangle;Melville;NY;11747;U.S.A. email;internet:geir.myrestrand@falconstor.com title:Senior Software Engineer tel;work:(631) 773-5842 tel;cell:(631) 747-5049 note;quoted-printable:Skype: gmyrestrand=0D=0A= MSN Messenger: gmyrestrand@hotmail.com=0D=0A= x-mozilla-html:FALSE url:http://www.falconstor.com version:2.1 end:vcard --------------070406040306080604080504-- From owner-xfs@oss.sgi.com Thu Dec 7 14:19:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 14:19:43 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7MJaaG003140 for ; Thu, 7 Dec 2006 14:19:37 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB7MIhQb014486; Thu, 7 Dec 2006 17:18:43 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB7MIhgF031891; Thu, 7 Dec 2006 17:18:43 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB7MIfiZ029462; Thu, 7 Dec 2006 17:18:42 -0500 Message-ID: <45789341.6000809@sandeen.net> Date: Thu, 07 Dec 2006 16:18:41 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: geir.myrestrand@falconstor.com CC: xfs@oss.sgi.com, nscott@aconex.com Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> <1165527628.30459.31.camel@edge> <45788CD1.9010509@falconstor.com> <1165529205.30459.36.camel@edge> <457892BB.1000203@falconstor.com> In-Reply-To: <457892BB.1000203@falconstor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9916 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 777 Lines: 23 Geir A. Myrestrand wrote: > Nathan Scott wrote: >> On Thu, 2006-12-07 at 16:51 -0500, Geir A. Myrestrand wrote: >>> Sorry Nathan, but I'm not sure I understand what you refer to with >>> "test out the latest" --are you referring to the kernel or XFS? >> Yes. :) Current mainline kernels, or CVS from oss.sgi.com would >> have this fix I'm thinking of. > > Thanks for the "clarification"... ;-) > > I'll try to update the XFS code first, hopefully it won't break too many > of the patches Eric had in his source RPM...but I will try to correct > them if they fail to apply cleanly... > > I'll keep you posted. > I would just get kernel-2.6.19 and run the test, see if it's fixed upstream, don't worry about merging & munging xfs code from one place o another... -Eric From owner-xfs@oss.sgi.com Thu Dec 7 14:27:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 14:27:29 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7MRLaG004613 for ; Thu, 7 Dec 2006 14:27:22 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120717181085:477 ; Thu, 7 Dec 2006 17:18:10 -0500 Message-ID: <457894DF.70603@falconstor.com> Date: Thu, 07 Dec 2006 17:25:35 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Eric Sandeen , nscott@aconex.com Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> <1165527628.30459.31.camel@edge> <45788CD1.9010509@falconstor.com> <1165529205.30459.36.camel@edge> <457892BB.1000203@falconstor.com> <45789341.6000809@sandeen.net> In-Reply-To: <45789341.6000809@sandeen.net> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 05:18:11 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 05:27:23 PM, Serialize complete at 12/07/2006 05:27:23 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9917 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 370 Lines: 16 Eric Sandeen wrote: > > I would just get kernel-2.6.19 and run the test, see if it's fixed > upstream, don't worry about merging & munging xfs code from one place o > another... > > -Eric I have SLES 10 (SUSE Linux Enterprise Server) installed on the same box, the kernel is 2.6.16.21-0.8-smp. Would it be worth checking that one first? -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Thu Dec 7 14:31:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 14:31:21 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7MVDaG005406 for ; Thu, 7 Dec 2006 14:31:14 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB7MUJJX022072; Thu, 7 Dec 2006 17:30:19 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB7MUJI2002593; Thu, 7 Dec 2006 17:30:19 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB7MUIH1030522; Thu, 7 Dec 2006 17:30:19 -0500 Message-ID: <457895FA.9010203@sandeen.net> Date: Thu, 07 Dec 2006 16:30:18 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: geir.myrestrand@falconstor.com CC: xfs@oss.sgi.com, nscott@aconex.com Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> <1165527628.30459.31.camel@edge> <45788CD1.9010509@falconstor.com> <1165529205.30459.36.camel@edge> <457892BB.1000203@falconstor.com> <45789341.6000809@sandeen.net> <457894DF.70603@falconstor.com> In-Reply-To: <457894DF.70603@falconstor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9918 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 399 Lines: 17 Geir A. Myrestrand wrote: > Eric Sandeen wrote: >> I would just get kernel-2.6.19 and run the test, see if it's fixed >> upstream, don't worry about merging & munging xfs code from one place o >> another... >> >> -Eric > > I have SLES 10 (SUSE Linux Enterprise Server) installed on the same box, > the kernel is 2.6.16.21-0.8-smp. Would it be worth checking that one > first? > Sure. -Eric From owner-xfs@oss.sgi.com Thu Dec 7 14:53:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 14:53:41 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7MrWaG008190 for ; Thu, 7 Dec 2006 14:53:33 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120717445498:481 ; Thu, 7 Dec 2006 17:44:54 -0500 Message-ID: <45789B27.1050507@falconstor.com> Date: Thu, 07 Dec 2006 17:52:23 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Eric Sandeen , nscott@aconex.com Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> <1165527628.30459.31.camel@edge> <45788CD1.9010509@falconstor.com> <1165529205.30459.36.camel@edge> <457892BB.1000203@falconstor.com> <45789341.6000809@sandeen.net> <457894DF.70603@falconstor.com> <457895FA.9010203@sandeen.net> In-Reply-To: <457895FA.9010203@sandeen.net> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 05:44:55 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 05:53:35 PM, Serialize complete at 12/07/2006 05:53:35 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9919 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 809 Lines: 31 Eric Sandeen wrote: > Geir A. Myrestrand wrote: >> Eric Sandeen wrote: >>> I would just get kernel-2.6.19 and run the test, see if it's fixed >>> upstream, don't worry about merging & munging xfs code from one place o >>> another... >>> >>> -Eric >> I have SLES 10 (SUSE Linux Enterprise Server) installed on the same box, >> the kernel is 2.6.16.21-0.8-smp. Would it be worth checking that one >> first? >> > > Sure. > > -Eric O'boy, looks like it happens on SLES10 as well. It froze on the first XFS freeze call, it does not return. strace -ff -o freeze-1.txt xfs_freeze -f /mnt/xfs \_ /bin/sh -f /usr/sbin/xfs_freeze -f /mnt/xfs \_ /usr/sbin/xfs_io -r -p xfs_freeze -x -c freeze /mnt/xfs A sync call hangs too. Looks like I need to test an even newer kernel... -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Thu Dec 7 14:54:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 14:55:01 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7MspaG008590 for ; Thu, 7 Dec 2006 14:54:52 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kB7MrwFj003045; Thu, 7 Dec 2006 17:53:58 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB7MrvXJ008271; Thu, 7 Dec 2006 17:53:57 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kB7MrtCk032655; Thu, 7 Dec 2006 17:53:57 -0500 Message-ID: <45789B83.5010800@sandeen.net> Date: Thu, 07 Dec 2006 16:53:55 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: geir.myrestrand@falconstor.com CC: xfs@oss.sgi.com, nscott@aconex.com Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> <1165527628.30459.31.camel@edge> <45788CD1.9010509@falconstor.com> <1165529205.30459.36.camel@edge> <457892BB.1000203@falconstor.com> <45789341.6000809@sandeen.net> <457894DF.70603@falconstor.com> <457895FA.9010203@sandeen.net> <45789B27.1050507@falconstor.com> In-Reply-To: <45789B27.1050507@falconstor.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9920 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 463 Lines: 15 Geir A. Myrestrand wrote: > O'boy, looks like it happens on SLES10 as well. It froze on the first > XFS freeze call, it does not return. > > strace -ff -o freeze-1.txt xfs_freeze -f /mnt/xfs > \_ /bin/sh -f /usr/sbin/xfs_freeze -f /mnt/xfs > \_ /usr/sbin/xfs_io -r -p xfs_freeze -x -c freeze /mnt/xfs > > A sync call hangs too. Looks like I need to test an even newer kernel... You don't have multiple concurrent freezes happening do you.... -Eric From owner-xfs@oss.sgi.com Thu Dec 7 15:10:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 15:10:08 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7NA0aG010906 for ; Thu, 7 Dec 2006 15:10:01 -0800 Received: from [10.3.4.137] ([10.3.4.137]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120718003432:487 ; Thu, 7 Dec 2006 18:00:34 -0500 Message-ID: <45789ED4.5000203@falconstor.com> Date: Thu, 07 Dec 2006 18:08:04 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Eric Sandeen , nscott@aconex.com Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45787ED4.5070801@falconstor.com> <1165525906.30459.25.camel@edge> <45788927.4030207@falconstor.com> <1165527628.30459.31.camel@edge> <45788CD1.9010509@falconstor.com> <1165529205.30459.36.camel@edge> <457892BB.1000203@falconstor.com> <45789341.6000809@sandeen.net> <457894DF.70603@falconstor.com> <457895FA.9010203@sandeen.net> <45789B27.1050507@falconstor.com> <45789B83.5010800@sandeen.net> In-Reply-To: <45789B83.5010800@sandeen.net> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 06:00:34 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 06:10:03 PM, Serialize complete at 12/07/2006 06:10:03 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 9921 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 1031 Lines: 28 Eric Sandeen wrote: > > You don't have multiple concurrent freezes happening do you.... > > -Eric > Nope, I don't need to. Now it happens on the first call to xfs_freeze. Sometimes in the past I did freeze, unfreeze, and then freeze before it happened, but this was still serialized from the same terminal window. Oh, could strace be the reason as to why it now always happens on the first invocation of the freeze command? Maybe it affects the wait calls... Well, without strace it would probably just happen on the second invocation of freeze (after unfreeze) like it did on RHELAS4U2... My test case is very simple, the only thing special is that I simplified my test case so much that I end up using a file as my disk (setup as a loopback device). However, the problem was initially discovered using a real disk, so I don't think that is the problem. If you're interested I can forward the test case involving probably less than 10 commands and a simple Perl script of maybe 20 lines. -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Thu Dec 7 15:28:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 15:28:13 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB7NS0aG013540 for ; Thu, 7 Dec 2006 15:28:03 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA27706; Fri, 8 Dec 2006 10:26:49 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB7NQk7Y56561608; Fri, 8 Dec 2006 10:26:47 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB7NQfeq55225709; Fri, 8 Dec 2006 10:26:41 +1100 (AEDT) Date: Fri, 8 Dec 2006 10:26:41 +1100 From: David Chinner To: "Geir A. Myrestrand" Cc: xfs@oss.sgi.com, Eric Sandeen Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms Message-ID: <20061207232641.GP33919298@melbourne.sgi.com> References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45785ABC.20208@falconstor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45785ABC.20208@falconstor.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 9922 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2492 Lines: 71 On Thu, Dec 07, 2006 at 01:17:32PM -0500, Geir A. Myrestrand wrote: > Eric Sandeen wrote: > >Geir A. Myrestrand wrote: > > > >>However, I run into issues with xfs_freeze as it often locks up when I > >>try to freeze a file system where there is I/O activity. Sometimes it > >>happen on the first xfs_freeze invocation to freeze the file system, > >>other times I have to unfreeze and then it happens on the second time I > >>freeze. xfs_freeze never returns when this happens. > >> > >>Looks like xfs_io get stuck --see partial output from `ps auxf`: > >> > >>strace -ff -o freeze.txt xfs_freeze -f /mnt/xfs > >> \_ /bin/sh -f /usr/sbin/xfs_freeze -f /mnt/xfs > >> \_ /usr/sbin/xfs_io -r -p xfs_freeze -x -c freeze /mnt/xfs > >> > >>Anyone else encountering this issue? Yes, and I fixed it about a 2 weeks ago. It's an ABBA deadlock between lookup of multiple, already dirty, metadata buffers and synchronous buftarg flushing (that occurs when trying to freeze a filesystem) I just went looking for the Take message in the archive, and it is not there. I cc all my takes to xfs@oss.sgi.com, so I'm not sure why it isn't in the archive.... http://oss.sgi.com/archives/xfs/2006-11/msg00291.html Was a followup cleanup of a problem found during review of the fix for the freeze problem. The text of the take message fo rthe fix is: Fix a synchronous buftarg flush deadlock when freezing. At the last stage of a freeze, we flush the buftarg synchronously over and over again until it succeeds twice without skipping any buffers. The delwri list flush skips pinned buffers, but tries to flush all others. It removes the buffers from the delwri list, then tries to lock them one at a time as it traverses the list to issue the I/O. It holds them locked until we issue all of the I/O and then unlocks them once we've waited for it to complete. The problem is that during a freeze, the filesystem may still be doing stuff - like flushing delalloc data buffers - in the background and hence we can be trying to lock buffers that were on the delwri list at the same time. Hence we can get ABBA deadlocks between threads doing allocation and the buftarg flush (freeze) thread. Fix it by skipping locked (and pinned) buffers as we traverse the delwri buffer list. ---- And the diff was: http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c.diff?r1=1.229;r2=1.230 Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 7 15:58:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 15:58:16 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB7Nw6aG017371 for ; Thu, 7 Dec 2006 15:58:08 -0800 Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id A7074AAC1BE; Fri, 8 Dec 2006 10:52:34 +1100 (EST) Subject: [PATCH] fix compiler warnings From: Nathan Scott Reply-To: nscott@aconex.com To: bnaujok@sgi.com, chatz@sgi.com Cc: xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-pl6DHbZIDDM10OZV7dtx" Organization: Aconex Date: Fri, 08 Dec 2006 10:57:08 +1100 Message-Id: <1165535828.30459.42.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 9923 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 45262 Lines: 936 --=-pl6DHbZIDDM10OZV7dtx Content-Type: text/plain Content-Transfer-Encoding: 7bit The xfsprogs userspace builds have been generating hundreds of warnings with recent gcc versions for some time, due to the char signedness inconsistencies we have in places. Here's a patch to clean that up, so we can at least see the interesting warnings cropping up now. cheers. -- Nathan --=-pl6DHbZIDDM10OZV7dtx Content-Disposition: attachment; filename=fix-gcc-warnings Content-Type: text/plain; name=fix-gcc-warnings; charset=UTF-8 Content-Transfer-Encoding: 8bit util.c: In function 'libxfs_dir_bogus_removename': util.c:470: warning: pointer targets in assignment differ in signedness util.c: In function 'libxfs_dir2_bogus_removename': util.c:531: warning: pointer targets in assignment differ in signedness gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir.c -fPIC -DPIC -o .libs/xfs_dir.o xfs_dir.c: In function 'xfs_dir_startup': xfs_dir.c:36: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir.c:37: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir.c: In function 'libxfs_dir_createname': xfs_dir.c:118: warning: pointer targets in assignment differ in signedness xfs_dir.c:120: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir.c: In function 'libxfs_dir_removename': xfs_dir.c:180: warning: pointer targets in assignment differ in signedness xfs_dir.c:182: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir.c: In function 'libxfs_dir_lookup': xfs_dir.c:224: warning: pointer targets in assignment differ in signedness xfs_dir.c:226: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir.c: In function 'libxfs_dir_replace': xfs_dir.c:269: warning: pointer targets in assignment differ in signedness xfs_dir.c:271: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir_leaf.c -fPIC -DPIC -o .libs/xfs_dir_leaf.o xfs_dir_leaf.c: In function 'libxfs_dir_shortform_to_leaf': xfs_dir_leaf.c:290: warning: pointer targets in assignment differ in signedness xfs_dir_leaf.c:306: warning: pointer targets in assignment differ in signedness xfs_dir_leaf.c:316: warning: pointer targets in assignment differ in signedness xfs_dir_leaf.c:319: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir_leaf.c: In function 'xfs_dir_leaf_to_shortform': xfs_dir_leaf.c:452: warning: pointer targets in assignment differ in signedness gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir2.c -fPIC -DPIC -o .libs/xfs_dir2.o xfs_dir2.c: In function 'libxfs_dir2_createname': xfs_dir2.c:99: warning: pointer targets in assignment differ in signedness xfs_dir2.c:101: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2.c: In function 'libxfs_dir2_lookup': xfs_dir2.c:150: warning: pointer targets in assignment differ in signedness xfs_dir2.c:152: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2.c: In function 'libxfs_dir2_removename': xfs_dir2.c:207: warning: pointer targets in assignment differ in signedness xfs_dir2.c:209: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2.c: In function 'libxfs_dir2_replace': xfs_dir2.c:262: warning: pointer targets in assignment differ in signedness xfs_dir2.c:264: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_attr_leaf.c -fPIC -DPIC -o .libs/xfs_attr_leaf.o xfs_attr_leaf.c: In function 'xfs_attr_shortform_to_leaf': xfs_attr_leaf.c:375: warning: pointer targets in assignment differ in signedness xfs_attr_leaf.c:377: warning: pointer targets in assignment differ in signedness xfs_attr_leaf.c:380: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_attr_leaf.c: In function 'xfs_attr_leaf_to_shortform': xfs_attr_leaf.c:513: warning: pointer targets in assignment differ in signedness xfs_attr_leaf.c:515: warning: pointer targets in assignment differ in signedness gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir2_block.c -fPIC -DPIC -o .libs/xfs_dir2_block.o xfs_dir2_block.c: In function 'libxfs_dir2_sf_to_block': xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_attr.c -fPIC -DPIC -o .libs/xfs_attr.o xfs_attr.c: In function 'libxfs_attr_set_int': xfs_attr.c:106: warning: pointer targets in assignment differ in signedness xfs_attr.c:108: warning: pointer targets in assignment differ in signedness xfs_attr.c: In function 'libxfs_attr_remove_int': xfs_attr.c:316: warning: pointer targets in assignment differ in signedness xfs_attr.c: In function 'xfs_attr_rmtval_set': xfs_attr.c:1292: warning: pointer targets in assignment differ in signedness gcc -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c fstype.c -fPIC -DPIC -o .libs/fstype.o fstype.c: In function 'is_reiserfs_magic_string': fstype.c:158: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:158: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:158: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:158: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:158: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:158: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:158: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:158: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:160: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:160: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:160: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:160: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:160: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:160: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:160: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:160: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c: In function 'fstype': fstype.c:222: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:222: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:222: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:222: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:222: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:222: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:222: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:222: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:228: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:228: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:228: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:228: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:228: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:228: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:228: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:228: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:234: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:234: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:234: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:234: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:234: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:234: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:234: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:234: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:235: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:235: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:235: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:235: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:235: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:235: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:235: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:235: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:236: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:236: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:236: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:236: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:237: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:237: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:237: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:237: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:237: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:237: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:237: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:237: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:238: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:238: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:238: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:238: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:238: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:238: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:238: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:238: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:241: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:241: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:241: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:241: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:241: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:241: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:241: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:241: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:242: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:242: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:242: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:242: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:242: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:242: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:242: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:242: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:243: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:243: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:243: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:243: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:243: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:243: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:243: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:243: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness fstype.c:244: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:244: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:244: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:244: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness fstype.c:244: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:244: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:244: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness fstype.c:244: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness gcc -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -DENABLE_READLINE -c -o check.o check.c check.c: In function ‘process_data_dir_v2’: check.c:2302: warning: pointer targets in passing argument 1 of ‘libxfs_da_hashname’ differ in signedness gcc -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -DENABLE_READLINE -c -o hash.o hash.c hash.c: In function ‘hash_f’: hash.c:55: warning: pointer targets in passing argument 1 of ‘libxfs_da_hashname’ differ in signedness phase6.c: In function ‘dir_bogus_removename’: phase6.c:391: warning: pointer targets in passing argument 3 of ‘libxfs_dir2_bogus_removename’ differ in signedness phase6.c:394: warning: pointer targets in passing argument 3 of ‘libxfs_dir_bogus_removename’ differ in signedness phase6.c: At top level: phase6.c:375: warning: ‘dir_removename’ defined but not used Index: xfsprogs/libxfs/util.c =================================================================== --- xfsprogs.orig/libxfs/util.c 2006-12-08 09:25:43.471005750 +1100 +++ xfsprogs/libxfs/util.c 2006-12-08 09:26:31.165986500 +1100 @@ -452,7 +452,7 @@ libxfs_bmap_next_offset( * This was originally in the kernel, but only used in xfs_repair. */ int -xfs_dir_bogus_removename(xfs_trans_t *trans, xfs_inode_t *dp, char *name, +xfs_dir_bogus_removename(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, xfs_fsblock_t *firstblock, xfs_bmap_free_t *flist, xfs_extlen_t total, xfs_dahash_t hashval, int namelen) { @@ -510,7 +510,7 @@ int xfs_dir2_bogus_removename( xfs_trans_t *tp, /* transaction pointer */ xfs_inode_t *dp, /* incore directory inode */ - char *name, /* name of entry to remove */ + uchar_t *name, /* name of entry to remove */ xfs_fsblock_t *first, /* bmap's firstblock */ xfs_bmap_free_t *flist, /* bmap's freeblock list */ xfs_extlen_t total, /* bmap's total block count */ Index: xfsprogs/include/libxfs.h =================================================================== --- xfsprogs.orig/include/libxfs.h 2006-12-08 09:25:43.547010500 +1100 +++ xfsprogs/include/libxfs.h 2006-12-08 09:26:31.165986500 +1100 @@ -429,33 +429,33 @@ extern void libxfs_dir_mount (xfs_mount_ extern void libxfs_dir2_mount (xfs_mount_t *); extern int libxfs_dir_init (xfs_trans_t *, xfs_inode_t *, xfs_inode_t *); extern int libxfs_dir2_init (xfs_trans_t *, xfs_inode_t *, xfs_inode_t *); -extern int libxfs_dir_createname (xfs_trans_t *, xfs_inode_t *, char *, +extern int libxfs_dir_createname (xfs_trans_t *, xfs_inode_t *, uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, xfs_bmap_free_t *, xfs_extlen_t); -extern int libxfs_dir2_createname (xfs_trans_t *, xfs_inode_t *, char *, +extern int libxfs_dir2_createname (xfs_trans_t *, xfs_inode_t *, uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, xfs_bmap_free_t *, xfs_extlen_t); extern int libxfs_dir_lookup (xfs_trans_t *, xfs_inode_t *, - char *, int, xfs_ino_t *); + uchar_t *, int, xfs_ino_t *); extern int libxfs_dir2_lookup (xfs_trans_t *, xfs_inode_t *, - char *, int, xfs_ino_t *); + uchar_t *, int, xfs_ino_t *); extern int libxfs_dir_replace (xfs_trans_t *, xfs_inode_t *, - char *, int, xfs_ino_t, xfs_fsblock_t *, + uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, xfs_bmap_free_t *, xfs_extlen_t); extern int libxfs_dir2_replace (xfs_trans_t *, xfs_inode_t *, - char *, int, xfs_ino_t, xfs_fsblock_t *, + uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, xfs_bmap_free_t *, xfs_extlen_t); extern int libxfs_dir_removename (xfs_trans_t *, xfs_inode_t *, - char *, int, xfs_ino_t, xfs_fsblock_t *, + uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, xfs_bmap_free_t *, xfs_extlen_t); extern int libxfs_dir2_removename (xfs_trans_t *, xfs_inode_t *, - char *, int, xfs_ino_t, xfs_fsblock_t *, + uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, xfs_bmap_free_t *, xfs_extlen_t); extern int libxfs_dir_bogus_removename (xfs_trans_t *, xfs_inode_t *, - char *, xfs_fsblock_t *, xfs_bmap_free_t *, + uchar_t *, xfs_fsblock_t *, xfs_bmap_free_t *, xfs_extlen_t, xfs_dahash_t, int); extern int libxfs_dir2_bogus_removename (xfs_trans_t *, xfs_inode_t *, - char *, xfs_fsblock_t *, xfs_bmap_free_t *, + uchar_t *, xfs_fsblock_t *, xfs_bmap_free_t *, xfs_extlen_t, xfs_dahash_t, int); Index: xfsprogs/libxfs/xfs_dir.c =================================================================== --- xfsprogs.orig/libxfs/xfs_dir.c 2006-12-08 09:25:43.479006250 +1100 +++ xfsprogs/libxfs/xfs_dir.c 2006-12-08 09:26:31.165986500 +1100 @@ -33,8 +33,8 @@ xfs_dahash_t xfs_dir_hash_dot, xfs_dir_h void xfs_dir_startup(void) { - xfs_dir_hash_dot = xfs_da_hashname(".", 1); - xfs_dir_hash_dotdot = xfs_da_hashname("..", 2); + xfs_dir_hash_dot = xfs_da_hashname((const uchar_t *) ".", 1); + xfs_dir_hash_dotdot = xfs_da_hashname((const uchar_t *) "..", 2); } /* @@ -99,7 +99,7 @@ xfs_dir_init(xfs_trans_t *trans, xfs_ino * Transitions directory from shortform to Btree as necessary. */ STATIC int /* error */ -xfs_dir_createname(xfs_trans_t *trans, xfs_inode_t *dp, char *name, +xfs_dir_createname(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, int namelen, xfs_ino_t inum, xfs_fsblock_t *firstblock, xfs_bmap_free_t *flist, xfs_extlen_t total) { @@ -165,7 +165,7 @@ xfs_dir_createname(xfs_trans_t *trans, x * Transitions directory from Btree to shortform as necessary. */ STATIC int /* error */ -xfs_dir_removename(xfs_trans_t *trans, xfs_inode_t *dp, char *name, +xfs_dir_removename(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, int namelen, xfs_ino_t ino, xfs_fsblock_t *firstblock, xfs_bmap_free_t *flist, xfs_extlen_t total) { @@ -209,7 +209,7 @@ xfs_dir_removename(xfs_trans_t *trans, x } STATIC int /* error */ -xfs_dir_lookup(xfs_trans_t *trans, xfs_inode_t *dp, char *name, int namelen, +xfs_dir_lookup(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, int namelen, xfs_ino_t *inum) { xfs_da_args_t args; @@ -251,7 +251,7 @@ xfs_dir_lookup(xfs_trans_t *trans, xfs_i } STATIC int /* error */ -xfs_dir_replace(xfs_trans_t *trans, xfs_inode_t *dp, char *name, int namelen, +xfs_dir_replace(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, int namelen, xfs_ino_t inum, xfs_fsblock_t *firstblock, xfs_bmap_free_t *flist, xfs_extlen_t total) { Index: xfsprogs/libxfs/xfs_dir2.c =================================================================== --- xfsprogs.orig/libxfs/xfs_dir2.c 2006-12-08 09:25:43.527009250 +1100 +++ xfsprogs/libxfs/xfs_dir2.c 2006-12-08 09:26:31.165986500 +1100 @@ -77,7 +77,7 @@ STATIC int /* error */ xfs_dir2_createname( xfs_trans_t *tp, /* transaction pointer */ xfs_inode_t *dp, /* incore directory inode */ - char *name, /* new entry name */ + uchar_t *name, /* new entry name */ int namelen, /* new entry name length */ xfs_ino_t inum, /* new entry inode number */ xfs_fsblock_t *first, /* bmap's firstblock */ @@ -133,7 +133,7 @@ STATIC int /* error */ xfs_dir2_lookup( xfs_trans_t *tp, /* transaction pointer */ xfs_inode_t *dp, /* incore directory inode */ - char *name, /* lookup name */ + uchar_t *name, /* lookup name */ int namelen, /* lookup name length */ xfs_ino_t *inum) /* out: inode number */ { @@ -188,7 +188,7 @@ STATIC int /* error */ xfs_dir2_removename( xfs_trans_t *tp, /* transaction pointer */ xfs_inode_t *dp, /* incore directory inode */ - char *name, /* name of entry to remove */ + uchar_t *name, /* name of entry to remove */ int namelen, /* name length of entry to remove */ xfs_ino_t ino, /* inode number of entry to remove */ xfs_fsblock_t *first, /* bmap's firstblock */ @@ -240,7 +240,7 @@ STATIC int /* error */ xfs_dir2_replace( xfs_trans_t *tp, /* transaction pointer */ xfs_inode_t *dp, /* incore directory inode */ - char *name, /* name of entry to replace */ + uchar_t *name, /* name of entry to replace */ int namelen, /* name length of entry to replace */ xfs_ino_t inum, /* new inode number */ xfs_fsblock_t *first, /* bmap's firstblock */ Index: xfsprogs/libxfs/xfs_dir_leaf.c =================================================================== --- xfsprogs.orig/libxfs/xfs_dir_leaf.c 2006-12-08 09:25:43.503007750 +1100 +++ xfsprogs/libxfs/xfs_dir_leaf.c 2006-12-08 09:26:31.165986500 +1100 @@ -287,7 +287,7 @@ xfs_dir_shortform_to_leaf(xfs_da_args_t goto out; xfs_da_buf_done(bp); - args.name = "."; + args.name = (const uchar_t *) "."; args.namelen = 1; args.hashval = xfs_dir_hash_dot; args.inumber = dp->i_ino; @@ -303,7 +303,7 @@ xfs_dir_shortform_to_leaf(xfs_da_args_t if (retval) goto out; - args.name = ".."; + args.name = (const uchar_t *) ".."; args.namelen = 2; args.hashval = xfs_dir_hash_dotdot; args.inumber = inumber; @@ -313,9 +313,9 @@ xfs_dir_shortform_to_leaf(xfs_da_args_t sfe = &sf->list[0]; for (i = 0; i < INT_GET(sf->hdr.count, ARCH_CONVERT); i++) { - args.name = (char *)(sfe->name); + args.name = (const uchar_t *)(sfe->name); args.namelen = sfe->namelen; - args.hashval = xfs_da_hashname((char *)(sfe->name), + args.hashval = xfs_da_hashname((const uchar_t *)(sfe->name), sfe->namelen); XFS_DIR_SF_GET_DIRINO(&sfe->inumber, &args.inumber); retval = xfs_dir_leaf_addname(&args); @@ -449,7 +449,7 @@ xfs_dir_leaf_to_shortform(xfs_da_args_t if (!entry->nameidx) continue; namest = XFS_DIR_LEAF_NAMESTRUCT(leaf, INT_GET(entry->nameidx, ARCH_CONVERT)); - args.name = (char *)(namest->name); + args.name = (const uchar_t *)(namest->name); args.namelen = entry->namelen; args.hashval = INT_GET(entry->hashval, ARCH_CONVERT); XFS_DIR_SF_GET_DIRINO(&namest->inumber, &args.inumber); Index: xfsprogs/libxfs/xfs_attr_leaf.c =================================================================== --- xfsprogs.orig/libxfs/xfs_attr_leaf.c 2006-12-08 09:25:43.539010000 +1100 +++ xfsprogs/libxfs/xfs_attr_leaf.c 2006-12-08 09:26:31.169986750 +1100 @@ -372,11 +372,11 @@ xfs_attr_shortform_to_leaf(xfs_da_args_t sfe = &sf->list[0]; for (i = 0; i < INT_GET(sf->hdr.count, ARCH_CONVERT); i++) { - nargs.name = (char *)sfe->nameval; + nargs.name = (const uchar_t *)sfe->nameval; nargs.namelen = sfe->namelen; - nargs.value = (char *)&sfe->nameval[nargs.namelen]; + nargs.value = (uchar_t *)&sfe->nameval[nargs.namelen]; nargs.valuelen = INT_GET(sfe->valuelen, ARCH_CONVERT); - nargs.hashval = xfs_da_hashname((char *)sfe->nameval, + nargs.hashval = xfs_da_hashname((const uchar_t *)sfe->nameval, sfe->namelen); nargs.flags = (sfe->flags & XFS_ATTR_SECURE) ? ATTR_SECURE : ((sfe->flags & XFS_ATTR_ROOT) ? ATTR_ROOT : 0); @@ -510,9 +510,9 @@ xfs_attr_leaf_to_shortform(xfs_dabuf_t * continue; ASSERT(entry->flags & XFS_ATTR_LOCAL); name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); - nargs.name = (char *)name_loc->nameval; + nargs.name = (const uchar_t *)name_loc->nameval; nargs.namelen = name_loc->namelen; - nargs.value = (char *)&name_loc->nameval[nargs.namelen]; + nargs.value = (uchar_t *)&name_loc->nameval[nargs.namelen]; nargs.valuelen = INT_GET(name_loc->valuelen, ARCH_CONVERT); nargs.hashval = INT_GET(entry->hashval, ARCH_CONVERT); nargs.flags = (entry->flags & XFS_ATTR_SECURE) ? ATTR_SECURE : Index: xfsprogs/libxfs/xfs_attr.c =================================================================== --- xfsprogs.orig/libxfs/xfs_attr.c 2006-12-08 09:27:45.790650250 +1100 +++ xfsprogs/libxfs/xfs_attr.c 2006-12-08 09:30:15.307994500 +1100 @@ -103,9 +103,9 @@ xfs_attr_set_int(xfs_inode_t *dp, const * Fill in the arg structure for this request. */ memset((char *)&args, 0, sizeof(args)); - args.name = name; + args.name = (const uchar_t *)name; args.namelen = namelen; - args.value = value; + args.value = (uchar_t *)value; args.valuelen = valuelen; args.flags = flags; args.hashval = xfs_da_hashname(args.name, args.namelen); @@ -313,7 +313,7 @@ xfs_attr_remove_int(xfs_inode_t *dp, con * Fill in the arg structure for this request. */ memset((char *)&args, 0, sizeof(args)); - args.name = name; + args.name = (const uchar_t *)name; args.namelen = namelen; args.flags = flags; args.hashval = xfs_da_hashname(args.name, args.namelen); @@ -1289,7 +1289,7 @@ xfs_attr_rmtval_set(xfs_da_args_t *args) dp = args->dp; mp = dp->i_mount; - src = args->value; + src = (xfs_caddr_t)args->value; /* * Find a "hole" in the attribute address space large enough for Index: xfsprogs/libxfs/xfs_dir2_block.c =================================================================== --- xfsprogs.orig/libxfs/xfs_dir2_block.c 2006-12-08 09:26:53.483381250 +1100 +++ xfsprogs/libxfs/xfs_dir2_block.c 2006-12-08 09:27:10.736459500 +1100 @@ -1046,7 +1046,7 @@ xfs_dir2_sf_to_block( tagp = XFS_DIR2_DATA_ENTRY_TAG_P(dep); INT_SET(*tagp, ARCH_CONVERT, (xfs_dir2_data_off_t)((char *)dep - (char *)block)); xfs_dir2_data_log_entry(tp, bp, dep); - INT_SET(blp[2 + i].hashval, ARCH_CONVERT, xfs_da_hashname((char *)sfep->name, sfep->namelen)); + INT_SET(blp[2 + i].hashval, ARCH_CONVERT, xfs_da_hashname((const uchar_t *)sfep->name, sfep->namelen)); INT_SET(blp[2 + i].address, ARCH_CONVERT, XFS_DIR2_BYTE_TO_DATAPTR(mp, (char *)dep - (char *)block)); offset = (int)((char *)(tagp + 1) - (char *)block); Index: xfsprogs/libdisk/fstype.c =================================================================== --- xfsprogs.orig/libdisk/fstype.c 2006-12-08 09:50:20.955342750 +1100 +++ xfsprogs/libdisk/fstype.c 2006-12-08 09:50:27.711765000 +1100 @@ -141,11 +141,11 @@ may_be_swap(const char *s) { /* rather weak necessary condition */ static int -may_be_adfs(const u_char *s) { - u_char *p; +may_be_adfs(const char *s) { + char *p; int sum; - p = (u_char *) s + 511; + p = (char *) s + 511; sum = 0; while(--p != s) sum = (sum >> 8) + (sum & 0xff) + *p; @@ -301,7 +301,7 @@ fstype(const char *device) { goto io_error; /* only a weak test */ - if (may_be_adfs((u_char *) &adfssb) + if (may_be_adfs((char *) &adfssb) && (adfsblksize(adfssb) >= 8 && adfsblksize(adfssb) <= 10)) type = "adfs"; Index: xfsprogs/libdisk/fstype.h =================================================================== --- xfsprogs.orig/libdisk/fstype.h 2006-12-08 09:49:45.061099500 +1100 +++ xfsprogs/libdisk/fstype.h 2006-12-08 09:51:00.657824000 +1100 @@ -38,8 +38,8 @@ #define MINIX2_SUPER_MAGIC 0x2468 /* minix v2, 14 char names */ #define MINIX2_SUPER_MAGIC2 0x2478 /* minix v2, 30 char names */ struct minix_super_block { - u_char s_dummy[16]; - u_char s_magic[2]; + char s_dummy[16]; + char s_magic[2]; }; #define minixmagic(s) assemble2le(s.s_magic) @@ -63,8 +63,8 @@ struct hs_volume_descriptor { #define EXT_SUPER_MAGIC 0x137D struct ext_super_block { - u_char s_dummy[56]; - u_char s_magic[2]; + char s_dummy[56]; + char s_magic[2]; }; #define extmagic(s) assemble2le(s.s_magic) @@ -72,37 +72,37 @@ struct ext_super_block { #define EXT2_SUPER_MAGIC 0xEF53 #define EXT3_FEATURE_COMPAT_HAS_JOURNAL 0x0004 struct ext2_super_block { - u_char s_dummy1[56]; - u_char s_magic[2]; - u_char s_dummy2[34]; - u_char s_feature_compat[4]; - u_char s_feature_incompat[4]; - u_char s_feature_ro_compat[4]; - u_char s_uuid[16]; - u_char s_volume_name[16]; - u_char s_dummy3[88]; - u_char s_journal_inum[4]; /* ext3 only */ + char s_dummy1[56]; + char s_magic[2]; + char s_dummy2[34]; + char s_feature_compat[4]; + char s_feature_incompat[4]; + char s_feature_ro_compat[4]; + char s_uuid[16]; + char s_volume_name[16]; + char s_dummy3[88]; + char s_journal_inum[4]; /* ext3 only */ }; #define ext2magic(s) assemble2le(s.s_magic) struct reiserfs_super_block { - u_char s_block_count[4]; - u_char s_free_blocks[4]; - u_char s_root_block[4]; - u_char s_journal_block[4]; - u_char s_journal_dev[4]; - u_char s_orig_journal_size[4]; - u_char s_journal_trans_max[4]; - u_char s_journal_block_count[4]; - u_char s_journal_max_batch[4]; - u_char s_journal_max_commit_age[4]; - u_char s_journal_max_trans_age[4]; - u_char s_blocksize[2]; - u_char s_oid_maxsize[2]; - u_char s_oid_cursize[2]; - u_char s_state[2]; - u_char s_magic[12]; + char s_block_count[4]; + char s_free_blocks[4]; + char s_root_block[4]; + char s_journal_block[4]; + char s_journal_dev[4]; + char s_orig_journal_size[4]; + char s_journal_trans_max[4]; + char s_journal_block_count[4]; + char s_journal_max_batch[4]; + char s_journal_max_commit_age[4]; + char s_journal_max_trans_age[4]; + char s_blocksize[2]; + char s_oid_maxsize[2]; + char s_oid_cursize[2]; + char s_state[2]; + char s_magic[12]; }; #define REISERFS_SUPER_MAGIC_STRING "ReIsErFs" #define REISER2FS_SUPER_MAGIC_STRING "ReIsEr2Fs" @@ -112,9 +112,9 @@ struct reiserfs_super_block #define _XIAFS_SUPER_MAGIC 0x012FD16D struct xiafs_super_block { - u_char s_boot_segment[512]; /* 1st sector reserved for boot */ - u_char s_dummy[60]; - u_char s_magic[4]; + char s_boot_segment[512]; /* 1st sector reserved for boot */ + char s_dummy[60]; + char s_magic[4]; }; #define xiafsmagic(s) assemble4le(s.s_magic) @@ -122,16 +122,16 @@ struct xiafs_super_block { #define UFS_SUPER_MAGIC_LE 0x00011954 #define UFS_SUPER_MAGIC_BE 0x54190100 struct ufs_super_block { - u_char s_dummy[0x55c]; - u_char s_magic[4]; + char s_dummy[0x55c]; + char s_magic[4]; }; #define ufsmagic(s) assemble4le(s.s_magic) /* From Richard.Russon@ait.co.uk Wed Feb 24 08:05:27 1999 */ #define NTFS_SUPER_MAGIC "NTFS" struct ntfs_super_block { - u_char s_dummy[3]; - u_char s_magic[4]; + char s_dummy[3]; + char s_magic[4]; }; /* From inspection of a few FAT filesystems - aeb */ @@ -139,33 +139,33 @@ struct ntfs_super_block { it looks like a primary has some directory entries where the extended has a partition table: IO.SYS, MSDOS.SYS, WINBOOT.SYS */ struct fat_super_block { - u_char s_dummy[3]; - u_char s_os[8]; /* "MSDOS5.0" or "MSWIN4.0" or "MSWIN4.1" */ + char s_dummy[3]; + char s_os[8]; /* "MSDOS5.0" or "MSWIN4.0" or "MSWIN4.1" */ /* mtools-3.9.4 writes "MTOOL394" */ - u_char s_dummy2[32]; - u_char s_label[11]; /* for DOS? */ - u_char s_fs[8]; /* "FAT12 " or "FAT16 " or all zero */ + char s_dummy2[32]; + char s_label[11]; /* for DOS? */ + char s_fs[8]; /* "FAT12 " or "FAT16 " or all zero */ /* OS/2 BM has "FAT " here. */ - u_char s_dummy3[9]; - u_char s_label2[11]; /* for Windows? */ - u_char s_fs2[8]; /* garbage or "FAT32 " */ + char s_dummy3[9]; + char s_label2[11]; /* for Windows? */ + char s_fs2[8]; /* garbage or "FAT32 " */ }; #define XFS_SUPER_MAGIC "XFSB" struct xfs_super_block { - u_char s_magic[4]; - u_char s_dummy[28]; - u_char s_uuid[16]; - u_char s_dummy2[60]; - u_char s_fname[12]; + char s_magic[4]; + char s_dummy[28]; + char s_uuid[16]; + char s_dummy2[60]; + char s_fname[12]; }; #define CRAMFS_SUPER_MAGIC 0x28cd3d45 #define CRAMFS_SUPER_MAGIC_BE 0x453dcd28 struct cramfs_super_block { - u_char s_magic[4]; - u_char s_dummy[12]; - u_char s_id[16]; + char s_magic[4]; + char s_dummy[12]; + char s_id[16]; }; #define cramfsmagic(s) assemble4le(s.s_magic) @@ -173,81 +173,81 @@ struct cramfs_super_block { #define HFSPLUS_SUPER_MAGIC 0x482B #define HFSPLUS_SUPER_VERSION 0x004 struct hfs_super_block { - u_char s_magic[2]; - u_char s_version[2]; + char s_magic[2]; + char s_version[2]; }; #define hfsmagic(s) assemble2le(s.s_magic) #define hfsversion(s) assemble2le(s.s_version) #define HPFS_SUPER_MAGIC 0xf995e849 struct hpfs_super_block { - u_char s_magic[4]; - u_char s_magic2[4]; + char s_magic[4]; + char s_magic2[4]; }; #define hpfsmagic(s) assemble4le(s.s_magic) struct adfs_super_block { - u_char s_dummy[448]; - u_char s_blksize[1]; - u_char s_dummy2[62]; - u_char s_checksum[1]; + char s_dummy[448]; + char s_blksize[1]; + char s_dummy2[62]; + char s_checksum[1]; }; #define adfsblksize(s) ((uint) s.s_blksize[0]) /* found in first 4 bytes of block 1 */ struct vxfs_super_block { - u_char s_magic[4]; + char s_magic[4]; }; #define vxfsmagic(s) assemble4le(s.s_magic) #define VXFS_SUPER_MAGIC 0xa501FCF5 struct jfs_super_block { char s_magic[4]; - u_char s_version[4]; - u_char s_dummy1[93]; + char s_version[4]; + char s_dummy1[93]; char s_fpack[11]; - u_char s_dummy2[24]; - u_char s_uuid[16]; + char s_dummy2[24]; + char s_uuid[16]; char s_label[16]; }; #define JFS_SUPER1_OFF 0x8000 #define JFS_MAGIC "JFS1" struct sysv_super_block { - u_char s_dummy1[504]; - u_char s_magic[4]; - u_char type[4]; + char s_dummy1[504]; + char s_magic[4]; + char type[4]; }; #define sysvmagic(s) assemble4le(s.s_magic) #define SYSV_SUPER_MAGIC 0xfd187e20 struct mdp_super_block { - u_char md_magic[4]; + char md_magic[4]; }; #define MD_SB_MAGIC 0xa92b4efc #define mdsbmagic(s) assemble4le(s.md_magic) struct ocfs_volume_header { - u_char minor_version[4]; - u_char major_version[4]; - u_char signature[128]; + char minor_version[4]; + char major_version[4]; + char signature[128]; }; struct ocfs_volume_label { - u_char disk_lock[48]; - u_char label[64]; - u_char label_len[2]; + char disk_lock[48]; + char label[64]; + char label_len[2]; }; #define ocfslabellen(o) assemble2le(o.label_len) #define OCFS_MAGIC "OracleCFS" static inline int -assemble2le(unsigned char *p) { +assemble2le(char *p) { return (p[0] | (p[1] << 8)); } static inline int -assemble4le(unsigned char *p) { +assemble4le(char *p) { return (p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24)); } Index: xfsprogs/db/check.c =================================================================== --- xfsprogs.orig/db/check.c 2006-12-08 09:55:43.307488500 +1100 +++ xfsprogs/db/check.c 2006-12-08 09:55:51.732015000 +1100 @@ -2299,7 +2299,7 @@ process_data_dir_v2( tag_err += INT_GET(*tagp, ARCH_CONVERT) != (char *)dep - (char *)data; addr = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, db, (char *)dep - (char *)data); - hash = libxfs_da_hashname((char *)dep->name, dep->namelen); + hash = libxfs_da_hashname((uchar_t *)dep->name, dep->namelen); dir_hash_add(hash, addr); ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); count++; Index: xfsprogs/db/hash.c =================================================================== --- xfsprogs.orig/db/hash.c 2006-12-08 09:56:12.929339750 +1100 +++ xfsprogs/db/hash.c 2006-12-08 09:56:25.478124000 +1100 @@ -52,7 +52,7 @@ hash_f( { xfs_dahash_t hashval; - hashval = libxfs_da_hashname(argv[1], (int)strlen(argv[1])); + hashval = libxfs_da_hashname((uchar_t *)argv[1], (int)strlen(argv[1])); dbprintf("0x%x\n", hashval); return 0; } Index: xfsprogs/mkfs/proto.c =================================================================== --- xfsprogs.orig/mkfs/proto.c 2006-12-08 09:57:08.404806750 +1100 +++ xfsprogs/mkfs/proto.c 2006-12-08 09:58:06.060410000 +1100 @@ -313,10 +313,10 @@ newdirent( int error; if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) - error = libxfs_dir2_createname(tp, pip, name, namelen, + error = libxfs_dir2_createname(tp, pip, (uchar_t*)name, namelen, inum, first, flist, total); else - error = libxfs_dir_createname(tp, pip, name, namelen, + error = libxfs_dir_createname(tp, pip, (uchar_t*)name, namelen, inum, first, flist, total); if (error) fail(_("directory createname error"), error); Index: xfsprogs/repair/phase6.c =================================================================== --- xfsprogs.orig/repair/phase6.c 2006-12-08 09:58:32.542065000 +1100 +++ xfsprogs/repair/phase6.c 2006-12-08 10:02:24.364553000 +1100 @@ -338,10 +338,12 @@ dir_createname(xfs_mount_t *mp, xfs_tran xfs_bmap_free_t *flist, xfs_extlen_t total) { if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) - return libxfs_dir2_createname(tp, pip, name, namelen, + return libxfs_dir2_createname(tp, pip, + (uchar_t *)name, namelen, inum, first, flist, total); else - return libxfs_dir_createname(tp, pip, name, namelen, + return libxfs_dir_createname(tp, pip, + (uchar_t *)name, namelen, inum, first, flist, total); } @@ -350,9 +352,11 @@ dir_lookup(xfs_mount_t *mp, xfs_trans_t int namelen, xfs_ino_t *inum) { if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) - return libxfs_dir2_lookup(tp, dp, name, namelen, inum); + return libxfs_dir2_lookup(tp, dp, + (uchar_t *)name, namelen, inum); else - return libxfs_dir_lookup(tp, dp, name, namelen, inum); + return libxfs_dir_lookup(tp, dp, + (uchar_t *)name, namelen, inum); } static int @@ -361,23 +365,12 @@ dir_replace(xfs_mount_t *mp, xfs_trans_t xfs_bmap_free_t *flist, xfs_extlen_t total) { if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) - return libxfs_dir2_replace(tp, dp, name, namelen, inum, + return libxfs_dir2_replace(tp, dp, + (uchar_t *)name, namelen, inum, firstblock, flist, total); else - return libxfs_dir_replace(tp, dp, name, namelen, inum, - firstblock, flist, total); -} - -static int -dir_removename(xfs_mount_t *mp, xfs_trans_t *tp, xfs_inode_t *dp, char *name, - int namelen, xfs_ino_t inum, xfs_fsblock_t *firstblock, - xfs_bmap_free_t *flist, xfs_extlen_t total) -{ - if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) - return libxfs_dir2_removename(tp, dp, name, namelen, inum, - firstblock, flist, total); - else - return libxfs_dir_removename(tp, dp, name, namelen, inum, + return libxfs_dir_replace(tp, dp, + (uchar_t *)name, namelen, inum, firstblock, flist, total); } @@ -387,10 +380,12 @@ dir_bogus_removename(xfs_mount_t *mp, xf xfs_extlen_t total, xfs_dahash_t hashval, int namelen) { if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) - return libxfs_dir2_bogus_removename(tp, dp, name, firstblock, + return libxfs_dir2_bogus_removename(tp, dp, + (uchar_t *)name, firstblock, flist, total, hashval, namelen); else - return libxfs_dir_bogus_removename(tp, dp, name, firstblock, + return libxfs_dir_bogus_removename(tp, dp, + (uchar_t *)name, firstblock, flist, total, hashval, namelen); } @@ -1863,7 +1858,7 @@ longform_dir2_rebuild( libxfs_trans_ihold(tp, ip); XFS_BMAP_INIT(&flist, &firstblock); - if ((error = libxfs_dir2_createname(tp, ip, (char*)p->name, + if ((error = libxfs_dir2_createname(tp, ip, (uchar_t *)p->name, p->namelen, p->inum, &firstblock, &flist, nres))) { do_warn( --=-pl6DHbZIDDM10OZV7dtx-- From owner-xfs@oss.sgi.com Thu Dec 7 16:02:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 16:02:39 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB802UaG018209 for ; Thu, 7 Dec 2006 16:02:32 -0800 Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id 917D8AAC1CE; Fri, 8 Dec 2006 10:56:58 +1100 (EST) Subject: [PATCH] fix header issue, bump version, update Debian packaging From: Nathan Scott Reply-To: nscott@aconex.com To: bnaujok@sgi.com, chatz@sgi.com Cc: xfs@oss.sgi.com Content-Type: multipart/mixed; boundary="=-oQyJxFaQuqTyCRVJilb/" Organization: Aconex Date: Fri, 08 Dec 2006 11:01:33 +1100 Message-Id: <1165536093.30459.48.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 9924 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 9135 Lines: 297 --=-oQyJxFaQuqTyCRVJilb/ Content-Type: text/plain Content-Transfer-Encoding: 7bit Here's a patch which reverts the header rename (since we simply can't go moving headers that we install in between minor releases) and updates the Debian packaging info so I can get a new version into the Debian archives. Please apply - thanks. cheers. -- Nathan --=-oQyJxFaQuqTyCRVJilb/ Content-Disposition: attachment; filename=fix-list-header-and-bump-debs Content-Type: text/x-patch; name=fix-list-header-and-bump-debs; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: xfsprogs/VERSION =================================================================== --- xfsprogs.orig/VERSION 2006-12-08 08:28:47.457518250 +1100 +++ xfsprogs/VERSION 2006-12-08 08:28:55.254005500 +1100 @@ -3,5 +3,5 @@ # PKG_MAJOR=2 PKG_MINOR=8 -PKG_REVISION=17 +PKG_REVISION=18 PKG_BUILD=1 Index: xfsprogs/debian/changelog =================================================================== --- xfsprogs.orig/debian/changelog 2006-12-08 08:28:47.549524000 +1100 +++ xfsprogs/debian/changelog 2006-12-08 10:06:07.942525750 +1100 @@ -1,3 +1,9 @@ +xfsprogs (2.8.18-1) unstable; urgency=low + + * New upstream release (closes: #399888) + + -- Nathan Scott Fri, 08 Dec 2006 08:30:29 +1100 + xfsprogs (2.8.12-1) unstable; urgency=low * New upstream release. Index: xfsprogs/doc/CHANGES =================================================================== --- xfsprogs.orig/doc/CHANGES 2006-12-08 08:28:47.481519750 +1100 +++ xfsprogs/doc/CHANGES 2006-12-08 09:26:19.197238500 +1100 @@ -1,4 +1,11 @@ -xfsprogs-2.8.17 +xfsprogs-2.8.18 (8 December 2006) + - is an installed file, we cannot simply rename it, + as other applications using it (accidentally or not) may break. + The xfs_list.h name was inconsistent with everything else too. + - Fix "pointer targets in assignment differ in signedness" warnings + - Update Debian packaging. + +xfsprogs-2.8.17 (?) - Fix up libxfs SEGV when attempting to mount a non-XFS filesystem. Thanks to Utako Kuzaka for this. - Fix up xfs_repair aborting if it finds an inode with an invalid Index: xfsprogs/include/Makefile =================================================================== --- xfsprogs.orig/include/Makefile 2006-12-08 08:28:47.569525250 +1100 +++ xfsprogs/include/Makefile 2006-12-08 08:30:58.893732500 +1100 @@ -18,14 +18,14 @@ TOPDIR = .. include $(TOPDIR)/include/builddefs -HFILES = cache.h handle.h jdm.h libxfs.h libxlog.h parent.h xfs.h xqm.h \ +HFILES = cache.h handle.h jdm.h list.h libxfs.h libxlog.h parent.h xfs.h xqm.h \ xfs_ag.h xfs_alloc.h xfs_alloc_btree.h xfs_arch.h xfs_attr_leaf.h \ xfs_attr_sf.h xfs_bit.h xfs_bmap.h xfs_bmap_btree.h xfs_btree.h \ xfs_buf_item.h xfs_da_btree.h xfs_dfrag.h xfs_dinode.h \ xfs_dir2.h xfs_dir2_block.h xfs_dir2_data.h xfs_dir2_leaf.h \ xfs_dir2_node.h xfs_dir2_sf.h xfs_dir_leaf.h xfs_dir_sf.h \ xfs_extfree_item.h xfs_fs.h xfs_ialloc.h xfs_ialloc_btree.h \ - xfs_imap.h xfs_inode.h xfs_inode_item.h xfs_inum.h xfs_list.h \ + xfs_imap.h xfs_inode.h xfs_inode_item.h xfs_inum.h \ xfs_log.h xfs_log_priv.h xfs_log_recover.h xfs_mount.h xfs_quota.h \ xfs_rtalloc.h xfs_sb.h xfs_trans.h xfs_trans_space.h xfs_types.h Index: xfsprogs/include/list.h =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ xfsprogs/include/list.h 2006-12-08 08:31:11.694532500 +1100 @@ -0,0 +1,88 @@ +/* + * Copyright (c) 2006 Silicon Graphics, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ +#ifndef __LIST_H__ +#define __LIST_H__ + +/* + * Simple, generic doubly-linked list implementation. + */ + +struct list_head { + struct list_head *next; + struct list_head *prev; +}; + +static inline void list_head_init(struct list_head *list) +{ + list->next = list->prev = list; +} + +static inline void list_head_destroy(struct list_head *list) +{ + list->next = list->prev = NULL; +} + +static inline void __list_add(struct list_head *add, + struct list_head *prev, struct list_head *next) +{ + next->prev = add; + add->next = next; + add->prev = prev; + prev->next = add; +} + +static inline void list_add(struct list_head *add, struct list_head *head) +{ + __list_add(add, head, head->next); +} + +static inline void list_add_tail(struct list_head *add, struct list_head *head) +{ + __list_add(add, head->prev, head); +} + +static inline void __list_del(struct list_head *prev, struct list_head *next) +{ + next->prev = prev; + prev->next = next; +} + +static inline void list_del_init(struct list_head *entry) +{ + __list_del(entry->prev, entry->next); + list_head_init(entry); +} + +static inline void list_move(struct list_head *list, struct list_head *head) +{ + __list_del(list->prev, list->next); + list_add(list, head); +} + +static inline void list_move_tail(struct list_head *list, struct list_head *head) +{ + __list_del(list->prev, list->next); + list_add_tail(list, head); +} + +static inline int list_empty(const struct list_head *head) +{ + return head->next == head; +} + +#endif /* __LIST_H__ */ Index: xfsprogs/include/xfs_list.h =================================================================== --- xfsprogs.orig/include/xfs_list.h 2006-12-08 08:28:47.637529500 +1100 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,88 +0,0 @@ -/* - * Copyright (c) 2006 Silicon Graphics, Inc. - * All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ -#ifndef __LIST_H__ -#define __LIST_H__ - -/* - * Simple, generic doubly-linked list implementation. - */ - -struct list_head { - struct list_head *next; - struct list_head *prev; -}; - -static inline void list_head_init(struct list_head *list) -{ - list->next = list->prev = list; -} - -static inline void list_head_destroy(struct list_head *list) -{ - list->next = list->prev = NULL; -} - -static inline void __list_add(struct list_head *add, - struct list_head *prev, struct list_head *next) -{ - next->prev = add; - add->next = next; - add->prev = prev; - prev->next = add; -} - -static inline void list_add(struct list_head *add, struct list_head *head) -{ - __list_add(add, head, head->next); -} - -static inline void list_add_tail(struct list_head *add, struct list_head *head) -{ - __list_add(add, head->prev, head); -} - -static inline void __list_del(struct list_head *prev, struct list_head *next) -{ - next->prev = prev; - prev->next = next; -} - -static inline void list_del_init(struct list_head *entry) -{ - __list_del(entry->prev, entry->next); - list_head_init(entry); -} - -static inline void list_move(struct list_head *list, struct list_head *head) -{ - __list_del(list->prev, list->next); - list_add(list, head); -} - -static inline void list_move_tail(struct list_head *list, struct list_head *head) -{ - __list_del(list->prev, list->next); - list_add_tail(list, head); -} - -static inline int list_empty(const struct list_head *head) -{ - return head->next == head; -} - -#endif /* __LIST_H__ */ Index: xfsprogs/include/libxfs.h =================================================================== --- xfsprogs.orig/include/libxfs.h 2006-12-08 08:34:46.039928250 +1100 +++ xfsprogs/include/libxfs.h 2006-12-08 10:05:46.501185750 +1100 @@ -24,7 +24,7 @@ #include #include -#include +#include #include #include Index: xfsprogs/libxfs/cache.c =================================================================== --- xfsprogs.orig/libxfs/cache.c 2006-12-08 08:35:35.479018000 +1100 +++ xfsprogs/libxfs/cache.c 2006-12-08 08:35:40.991362500 +1100 @@ -23,7 +23,7 @@ #include #include -#include +#include #include #define CACHE_DEBUG 1 --=-oQyJxFaQuqTyCRVJilb/-- From owner-xfs@oss.sgi.com Thu Dec 7 16:05:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 16:05:39 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB805VaG018828 for ; Thu, 7 Dec 2006 16:05:32 -0800 Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id 04C90AAC1CE for ; Fri, 8 Dec 2006 10:59:59 +1100 (EST) Subject: QA regression test issues From: Nathan Scott Reply-To: nscott@aconex.com To: xfs@oss.sgi.com Content-Type: text/plain Organization: Aconex Date: Fri, 08 Dec 2006 11:04:34 +1100 Message-Id: <1165536274.30459.51.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9925 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 278 Lines: 13 Hi, Is it just me or are many of the QA tests broken with current versions of xfs_repair? In the "repair" check group, 3 out of 5 tests are not passing atm (with/without my last coupla patches). Can the person who broke 'em, fix 'em please? :) Thanks! cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Dec 7 16:33:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 16:33:11 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB80WxaG026986 for ; Thu, 7 Dec 2006 16:33:01 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA29025; Fri, 8 Dec 2006 11:10:51 +1100 Message-Id: <200612080010.LAA29025@larry.melbourne.sgi.com> From: "Barry Naujok" To: , Subject: RE: QA regression test issues Date: Fri, 8 Dec 2006 11:16:55 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccaXJFGF9OsYf2uSESW3iuSTPLI6QAAWZVg In-Reply-To: <1165536274.30459.51.camel@edge> X-archive-position: 9927 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 794 Lines: 28 Yes, xfs_repair has more progress information in recent versions. The XFS QA tests are being updated with new xfs_repair filterings to filter out that progress info as it's not required for QA. I'll be doing further xfs_repair output cleanup at a later stage. > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Nathan Scott > Sent: Friday, 8 December 2006 11:05 AM > To: xfs@oss.sgi.com > Subject: QA regression test issues > > Hi, > > Is it just me or are many of the QA tests broken with current versions > of xfs_repair? In the "repair" check group, 3 out of 5 tests are not > passing atm (with/without my last coupla patches). > > Can the person who broke 'em, fix 'em please? :) Thanks! > > cheers. > > -- > Nathan > > From owner-xfs@oss.sgi.com Thu Dec 7 18:02:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 18:02:53 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB822aaG002542 for ; Thu, 7 Dec 2006 18:02:43 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA01658; Fri, 8 Dec 2006 13:01:39 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB821c7Y56557110; Fri, 8 Dec 2006 13:01:38 +1100 (AEDT) Received: (from bnaujok@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB821XAk56553876; Fri, 8 Dec 2006 13:01:33 +1100 (AEDT) Date: Fri, 8 Dec 2006 13:01:33 +1100 (AEDT) From: Barry Naujok Message-Id: <200612080201.kB821XAk56553876@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 958795 - [PATCH 1/2]segmentation fault in xfs_io mread/mwrite command X-archive-position: 9928 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1364 Lines: 35 Fix up xfs_io mread command that read from the wrong offset Date: Fri Dec 8 13:00:18 AEDT 2006 Workarea: snort.melbourne.sgi.com:/home/bnaujok/isms/repair Inspected by: utako@tnes.nec.co.jp The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:27661a xfstests/141 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/141 xfstests/141.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/141.out - Added QA test for xfs_io mread command xfsprogs/doc/CHANGES - 1.230 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.230&r2=text&tr2=1.229&f=h - Fix up xfs_io mread command that read from the wrong offset xfstests/group - 1.96 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/group.diff?r1=text&tr1=1.96&r2=text&tr2=1.95&f=h - Added QA test for xfs_io mread command xfsprogs/man/man8/xfs_io.8 - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/xfs_io.8.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h - Updated manpage for some xfs_io commands xfsprogs/io/mmap.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/io/mmap.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h - Fix up xfs_io mread command that read from the wrong offset From owner-xfs@oss.sgi.com Thu Dec 7 18:28:31 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 18:28:40 -0800 (PST) Received: from mx1.suse.de (ns1.suse.de [195.135.220.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB82SUaG005584 for ; Thu, 7 Dec 2006 18:28:31 -0800 Received: from Relay1.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 6DBDE12294; Fri, 8 Dec 2006 03:08:39 +0100 (CET) From: Andreas Gruenbacher Organization: SUSE Labs, Novell To: Timothy Shimmin Subject: Re: [PATCH] libattr 2.4.32 arm eabi system call calling convention Date: Thu, 7 Dec 2006 18:07:54 -0800 User-Agent: KMail/1.9.5 Cc: Christoph Hellwig , Lennert Buytenhek , xfs@oss.sgi.com, linux-arm@lists.arm.linux.org.uk References: <20061130025459.GA23869@xi.wantstofly.org> <20061130092853.GB1534@infradead.org> In-Reply-To: <20061130092853.GB1534@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612071807.55023.agruen@suse.de> X-archive-position: 9929 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: agruen@suse.de Precedence: bulk X-list: xfs Content-Length: 924 Lines: 25 Hello, On Thursday 30 November 2006 01:28, Christoph Hellwig wrote: > On Thu, Nov 30, 2006 at 03:54:59AM +0100, Lennert Buytenhek wrote: > > When building for EABI, a different system call calling convention is > > used where system calls are numbered starting from zero, not 0x900000 > > as in the old ABI. This was causing 'ls -al' with an ls binary that > > was built with xattr support to SIGILL. > > Please just rip out the direct syscalls. The days glibc provices all > the xattr syscalls in sys/xattr.h, and libattr should just forward to > those. Yes, makes sense these days. Thanks for paying attention, Christoph. Tim, who from the SGI side is taking care of the acl and attr packages in the xfs-cmds repository these days? Would you be doing this change, or are you waiting for a patch? Thanks, Andreas PS. I hope we'll meet at linux.conf.au this January in Sydney, or in Melbourne some days later :-) From owner-xfs@oss.sgi.com Thu Dec 7 18:56:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 18:57:00 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB82upaG008648 for ; Thu, 7 Dec 2006 18:56:52 -0800 Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id 83508AAC1A8; Fri, 8 Dec 2006 13:51:16 +1100 (EST) Subject: Re: [PATCH] libattr 2.4.32 arm eabi system call calling convention From: Nathan Scott Reply-To: nscott@aconex.com To: Andreas Gruenbacher Cc: Timothy Shimmin , Christoph Hellwig , Lennert Buytenhek , xfs@oss.sgi.com, linux-arm@lists.arm.linux.org.uk In-Reply-To: <200612071807.55023.agruen@suse.de> References: <20061130025459.GA23869@xi.wantstofly.org> <20061130092853.GB1534@infradead.org> <200612071807.55023.agruen@suse.de> Content-Type: text/plain Organization: Aconex Date: Fri, 08 Dec 2006 13:55:53 +1100 Message-Id: <1165546553.30459.71.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9930 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 1250 Lines: 35 On Thu, 2006-12-07 at 18:07 -0800, Andreas Gruenbacher wrote: > Hello, Hi Andreas, > On Thursday 30 November 2006 01:28, Christoph Hellwig wrote: > > On Thu, Nov 30, 2006 at 03:54:59AM +0100, Lennert Buytenhek wrote: > > > When building for EABI, a different system call calling convention is > > > used where system calls are numbered starting from zero, not 0x900000 > > > as in the old ABI. This was causing 'ls -al' with an ls binary that > > > was built with xattr support to SIGILL. > > > > Please just rip out the direct syscalls. The days glibc provices all > > the xattr syscalls in sys/xattr.h, and libattr should just forward to > > those. > > Yes, makes sense these days. Thanks for paying attention, Christoph. > > Tim, who from the SGI side is taking care of the acl and attr packages in the > xfs-cmds repository these days? Would you be doing this change, or are you > waiting for a patch? Tim's on holiday atm. I'll cook up a patch (I have another attr patch from someone I need to get merged too), and get someone to check it in. > PS. I hope we'll meet at linux.conf.au this January in Sydney, or in Melbourne > some days later :-) I'll see you there too (I'm looking forward to your LCA talk ;) cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Dec 7 19:00:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 19:00:34 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB830OaG009515 for ; Thu, 7 Dec 2006 19:00:26 -0800 Received: from [10.1.10.197] ([10.1.10.197]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006120721512369:528 ; Thu, 7 Dec 2006 21:51:23 -0500 Message-ID: <4578D4DE.1090400@falconstor.com> Date: Thu, 07 Dec 2006 21:58:38 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: New CentOS4/RHEL4-compatible xfs module rpms References: <4560AB84.9060200@sandeen.net> <45784E71.4080605@falconstor.com> <457854CB.5030507@sandeen.net> <45785ABC.20208@falconstor.com> <20061207232641.GP33919298@melbourne.sgi.com> In-Reply-To: <20061207232641.GP33919298@melbourne.sgi.com> X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 09:51:23 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/07/2006 10:00:28 PM, Serialize complete at 12/07/2006 10:00:28 PM Content-Type: multipart/mixed; boundary="------------060405040607010202040606" X-archive-position: 9931 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 2781 Lines: 87 This is a multi-part message in MIME format. --------------060405040607010202040606 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed David Chinner wrote: > On Thu, Dec 07, 2006 at 01:17:32PM -0500, Geir A. Myrestrand wrote: >>> Geir A. Myrestrand wrote: >>> >>>> However, I run into issues with xfs_freeze as it often locks up when I >>>> try to freeze a file system where there is I/O activity. Sometimes it >>>> happen on the first xfs_freeze invocation to freeze the file system, >>>> other times I have to unfreeze and then it happens on the second time I >>>> freeze. xfs_freeze never returns when this happens. >>>> >>>> Looks like xfs_io get stuck --see partial output from `ps auxf`: >>>> >>>> strace -ff -o freeze.txt xfs_freeze -f /mnt/xfs >>>> \_ /bin/sh -f /usr/sbin/xfs_freeze -f /mnt/xfs >>>> \_ /usr/sbin/xfs_io -r -p xfs_freeze -x -c freeze /mnt/xfs >>>> >>>> Anyone else encountering this issue? > > Yes, and I fixed it about a 2 weeks ago. It's an ABBA deadlock between > lookup of multiple, already dirty, metadata buffers and synchronous buftarg > flushing (that occurs when trying to freeze a filesystem) > > That is awesome news, mate! :-) > The problem is that during a freeze, the filesystem may > still be doing stuff - like flushing delalloc data buffers - > in the background and hence we can be trying to lock buffers > that were on the delwri list at the same time. Hence we can > get ABBA deadlocks between threads doing allocation and the > buftarg flush (freeze) thread. That sounds like an accurate description of my test environment. I bet this is the issue... > Fix it by skipping locked (and pinned) buffers as we traverse the > delwri buffer list. Good to know that you're one step ahead! > And the diff was: > > http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xfs/linux-2.6/xfs_buf.c.diff?r1=1.229;r2=1.230 Excellent. I will try this tomorrow (it's late in the evening here in New York now). I'll let you know how it works out. Thanks! -- Geir A. Myrestrand --------------060405040607010202040606 Content-Transfer-Encoding: 7bit Content-Type: text/x-vcard; charset=utf-8; name="geir.myrestrand.vcf" Content-Disposition: attachment; filename="geir.myrestrand.vcf" begin:vcard fn:Geir A. Myrestrand n:Myrestrand;Geir A. org:FalconStor Software, Inc. adr:Suite 2S01;;2 Huntington Quadrangle;Melville;NY;11747;U.S.A. email;internet:geir.myrestrand@falconstor.com title:Senior Software Engineer tel;work:(631) 773-5842 tel;cell:(631) 747-5049 note;quoted-printable:Skype: gmyrestrand=0D=0A= MSN Messenger: gmyrestrand@hotmail.com=0D=0A= x-mozilla-html:FALSE url:http://www.falconstor.com version:2.1 end:vcard --------------060405040607010202040606-- From owner-xfs@oss.sgi.com Thu Dec 7 19:29:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 19:29:26 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB83THaG012604 for ; Thu, 7 Dec 2006 19:29:18 -0800 Received: from edge (unknown [192.168.200.2]) by postoffice.aconex.com (Postfix) with ESMTP id 158F6AAC19B; Fri, 8 Dec 2006 14:23:43 +1100 (EST) Subject: [PATCH] update attr package From: Nathan Scott Reply-To: nscott@aconex.com To: xfs@oss.sgi.com Cc: agruen@suse.de Content-Type: multipart/mixed; boundary="=-gEoE8o8ACRhJs/HoFpFX" Organization: Aconex Date: Fri, 08 Dec 2006 14:28:19 +1100 Message-Id: <1165548500.30459.75.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 9932 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 10691 Lines: 339 --=-gEoE8o8ACRhJs/HoFpFX Content-Type: text/plain Content-Transfer-Encoding: 7bit Remove system call stubs from libattr, we always defer to the libc interfaces in this day and age. Removes a SIGILL delivery from the ARM EABI, reported by Lennert Buytenhek. Also updates Debian packaging. -- Nathan --=-gEoE8o8ACRhJs/HoFpFX Content-Disposition: attachment; filename=remove-syscalls Content-Type: text/x-patch; name=remove-syscalls; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: attr/libattr/Makefile =================================================================== --- attr.orig/libattr/Makefile 2006-12-08 13:50:25.299558000 +1100 +++ attr/libattr/Makefile 2006-12-08 13:50:38.096357750 +1100 @@ -15,12 +15,6 @@ LT_AGE = 1 CFILES = libattr.c attr_copy_fd.c attr_copy_file.c attr_copy_check.c HFILES = libattr.h -ifeq ($(PKG_PLATFORM),linux) -CFILES += syscalls.c -else -LSRCFILES = syscalls.c -endif - LCFLAGS = -include libattr.h default: $(LTLIBRARY) Index: attr/libattr/syscalls.c =================================================================== --- attr.orig/libattr/syscalls.c 2006-12-08 13:50:45.660830500 +1100 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,259 +0,0 @@ -/* - * Copyright (c) 2001-2002 Silicon Graphics, Inc. - * All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ - -/* - * The use of the syscall() function is an additional level of - * indirection. This avoids the dependency on kernel sources. - */ - -#include -#include - -#if defined (__i386__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_setxattr 226 -# define __NR_lsetxattr 227 -# define __NR_fsetxattr 228 -# define __NR_getxattr 229 -# define __NR_lgetxattr 230 -# define __NR_fgetxattr 231 -# define __NR_listxattr 232 -# define __NR_llistxattr 233 -# define __NR_flistxattr 234 -# define __NR_removexattr 235 -# define __NR_lremovexattr 236 -# define __NR_fremovexattr 237 -#elif defined (__sparc__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_setxattr 169 -# define __NR_lsetxattr 170 -# define __NR_fsetxattr 171 -# define __NR_getxattr 172 -# define __NR_lgetxattr 173 -# define __NR_fgetxattr 177 -# define __NR_listxattr 178 -# define __NR_llistxattr 179 -# define __NR_flistxattr 180 -# define __NR_removexattr 181 -# define __NR_lremovexattr 182 -# define __NR_fremovexattr 186 -#elif defined (__ia64__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_setxattr 1217 -# define __NR_lsetxattr 1218 -# define __NR_fsetxattr 1219 -# define __NR_getxattr 1220 -# define __NR_lgetxattr 1221 -# define __NR_fgetxattr 1222 -# define __NR_listxattr 1223 -# define __NR_llistxattr 1224 -# define __NR_flistxattr 1225 -# define __NR_removexattr 1226 -# define __NR_lremovexattr 1227 -# define __NR_fremovexattr 1228 -#elif defined (__powerpc__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_setxattr 209 -# define __NR_lsetxattr 210 -# define __NR_fsetxattr 211 -# define __NR_getxattr 212 -# define __NR_lgetxattr 213 -# define __NR_fgetxattr 214 -# define __NR_listxattr 215 -# define __NR_llistxattr 216 -# define __NR_flistxattr 217 -# define __NR_removexattr 218 -# define __NR_lremovexattr 219 -# define __NR_fremovexattr 220 -#elif defined (__x86_64__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_setxattr 188 -# define __NR_lsetxattr 189 -# define __NR_fsetxattr 190 -# define __NR_getxattr 191 -# define __NR_lgetxattr 192 -# define __NR_fgetxattr 193 -# define __NR_listxattr 194 -# define __NR_llistxattr 195 -# define __NR_flistxattr 196 -# define __NR_removexattr 197 -# define __NR_lremovexattr 198 -# define __NR_fremovexattr 199 -#elif defined (__s390__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_setxattr 224 -# define __NR_lsetxattr 225 -# define __NR_fsetxattr 226 -# define __NR_getxattr 227 -# define __NR_lgetxattr 228 -# define __NR_fgetxattr 229 -# define __NR_listxattr 230 -# define __NR_llistxattr 231 -# define __NR_flistxattr 232 -# define __NR_removexattr 233 -# define __NR_lremovexattr 234 -# define __NR_fremovexattr 235 -#elif defined (__arm__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_SYSCALL_BASE 0x900000 -# define __NR_setxattr (__NR_SYSCALL_BASE+226) -# define __NR_lsetxattr (__NR_SYSCALL_BASE+227) -# define __NR_fsetxattr (__NR_SYSCALL_BASE+228) -# define __NR_getxattr (__NR_SYSCALL_BASE+229) -# define __NR_lgetxattr (__NR_SYSCALL_BASE+230) -# define __NR_fgetxattr (__NR_SYSCALL_BASE+231) -# define __NR_listxattr (__NR_SYSCALL_BASE+232) -# define __NR_llistxattr (__NR_SYSCALL_BASE+233) -# define __NR_flistxattr (__NR_SYSCALL_BASE+234) -# define __NR_removexattr (__NR_SYSCALL_BASE+235) -# define __NR_lremovexattr (__NR_SYSCALL_BASE+236) -# define __NR_fremovexattr (__NR_SYSCALL_BASE+237) -#elif defined (__mips64__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_Linux 5000 -# define __NR_setxattr (__NR_Linux + 217) -# define __NR_lsetxattr (__NR_Linux + 218) -# define __NR_fsetxattr (__NR_Linux + 219) -# define __NR_getxattr (__NR_Linux + 220) -# define __NR_lgetxattr (__NR_Linux + 221) -# define __NR_fgetxattr (__NR_Linux + 222) -# define __NR_listxattr (__NR_Linux + 223) -# define __NR_llistxattr (__NR_Linux + 224) -# define __NR_flistxattr (__NR_Linux + 225) -# define __NR_removexattr (__NR_Linux + 226) -# define __NR_lremovexattr (__NR_Linux + 227) -# define __NR_fremovexattr (__NR_Linux + 228) -#elif defined (__mips__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_Linux 4000 -# define __NR_setxattr (__NR_Linux + 224) -# define __NR_lsetxattr (__NR_Linux + 225) -# define __NR_fsetxattr (__NR_Linux + 226) -# define __NR_getxattr (__NR_Linux + 227) -# define __NR_lgetxattr (__NR_Linux + 228) -# define __NR_fgetxattr (__NR_Linux + 229) -# define __NR_listxattr (__NR_Linux + 230) -# define __NR_llistxattr (__NR_Linux + 231) -# define __NR_flistxattr (__NR_Linux + 232) -# define __NR_removexattr (__NR_Linux + 233) -# define __NR_lremovexattr (__NR_Linux + 234) -# define __NR_fremovexattr (__NR_Linux + 235) -#elif defined (__alpha__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_setxattr 382 -# define __NR_lsetxattr 383 -# define __NR_fsetxattr 384 -# define __NR_getxattr 385 -# define __NR_lgetxattr 386 -# define __NR_fgetxattr 387 -# define __NR_listxattr 388 -# define __NR_llistxattr 389 -# define __NR_flistxattr 390 -# define __NR_removexattr 391 -# define __NR_lremovexattr 392 -# define __NR_fremovexattr 393 -#elif defined (__mc68000__) -# define HAVE_XATTR_SYSCALLS 1 -# define __NR_setxattr 223 -# define __NR_lsetxattr 224 -# define __NR_fsetxattr 225 -# define __NR_getxattr 226 -# define __NR_lgetxattr 227 -# define __NR_fgetxattr 228 -# define __NR_listxattr 229 -# define __NR_llistxattr 230 -# define __NR_flistxattr 231 -# define __NR_removexattr 232 -# define __NR_lremovexattr 233 -# define __NR_fremovexattr 234 -#else -# warning "Extended attribute syscalls undefined for this architecture" -# define HAVE_XATTR_SYSCALLS 0 -#endif - -#if HAVE_XATTR_SYSCALLS -# define SYSCALL(args...) syscall(args) -#else -# define SYSCALL(args...) ( errno = ENOSYS, -1 ) -#endif - -int setxattr (const char *path, const char *name, - void *value, size_t size, int flags) -{ - return SYSCALL(__NR_setxattr, path, name, value, size, flags); -} - -int lsetxattr (const char *path, const char *name, - void *value, size_t size, int flags) -{ - return SYSCALL(__NR_lsetxattr, path, name, value, size, flags); -} - -int fsetxattr (int filedes, const char *name, - void *value, size_t size, int flags) -{ - return SYSCALL(__NR_fsetxattr, filedes, name, value, size, flags); -} - -ssize_t getxattr (const char *path, const char *name, - void *value, size_t size) -{ - return SYSCALL(__NR_getxattr, path, name, value, size); -} - -ssize_t lgetxattr (const char *path, const char *name, - void *value, size_t size) -{ - return SYSCALL(__NR_lgetxattr, path, name, value, size); -} - -ssize_t fgetxattr (int filedes, const char *name, - void *value, size_t size) -{ - return SYSCALL(__NR_fgetxattr, filedes, name, value, size); -} - -ssize_t listxattr (const char *path, char *list, size_t size) -{ - return SYSCALL(__NR_listxattr, path, list, size); -} - -ssize_t llistxattr (const char *path, char *list, size_t size) -{ - return SYSCALL(__NR_llistxattr, path, list, size); -} - -ssize_t flistxattr (int filedes, char *list, size_t size) -{ - return SYSCALL(__NR_flistxattr, filedes, list, size); -} - -int removexattr (const char *path, const char *name) -{ - return SYSCALL(__NR_removexattr, path, name); -} - -int lremovexattr (const char *path, const char *name) -{ - return SYSCALL(__NR_lremovexattr, path, name); -} - -int fremovexattr (int filedes, const char *name) -{ - return SYSCALL(__NR_fremovexattr, filedes, name); -} Index: attr/VERSION =================================================================== --- attr.orig/VERSION 2006-12-08 14:09:37.019536000 +1100 +++ attr/VERSION 2006-12-08 14:09:43.027911500 +1100 @@ -3,5 +3,5 @@ # PKG_MAJOR=2 PKG_MINOR=4 -PKG_REVISION=34 +PKG_REVISION=35 PKG_BUILD=0 Index: attr/debian/changelog =================================================================== --- attr.orig/debian/changelog 2006-12-08 14:09:37.095540750 +1100 +++ attr/debian/changelog 2006-12-08 14:12:56.956031250 +1100 @@ -1,3 +1,9 @@ +attr (2.4.35-1) unstable; urgency=low + + * New upstream release + + -- Nathan Scott Fri, 08 Dec 2006 14:12:25 +1100 + attr (2.4.33-1) unstable; urgency=low * New upstream release Index: attr/doc/CHANGES =================================================================== --- attr.orig/doc/CHANGES 2006-12-08 14:09:37.039537250 +1100 +++ attr/doc/CHANGES 2006-12-08 14:25:50.284361250 +1100 @@ -1,3 +1,8 @@ +attr-2.4.35 (8 December 2006) + - Remove system call stubs from libattr, we always defer to + the libc interfaces in this day and age. Removes a SIGILL + delivery from the ARM EABI, reported by Lennert Buytenhek. + attr-2.4.34 (14 July 2006) - Fix issues with makedepend on libtool libraries. --=-gEoE8o8ACRhJs/HoFpFX-- From owner-xfs@oss.sgi.com Thu Dec 7 21:34:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 21:34:11 -0800 (PST) Received: from omx1.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB85Y0qw031342 for ; Thu, 7 Dec 2006 21:34:01 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by omx1.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with SMTP id kB85GZDW030162 for ; Thu, 7 Dec 2006 23:16:37 -0600 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA06016; Fri, 8 Dec 2006 16:16:33 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB85GV7Y56557709; Fri, 8 Dec 2006 16:16:32 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB85GUfI56586840; Fri, 8 Dec 2006 16:16:30 +1100 (AEDT) Date: Fri, 8 Dec 2006 16:16:29 +1100 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , Klaus Strebel , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Reduce in-core superblock lock contention near ENOSPC Message-ID: <20061208051629.GV33919298@melbourne.sgi.com> References: <20061123044122.GU11034@melbourne.sgi.com> <456F1CFC.2060705@sgi.com> <20061130223810.GO37654165@melbourne.sgi.com> <457080EA.1010807@sgi.com> <20061203234928.GA37654165@melbourne.sgi.com> <45755C26.2080505@gmx.net> <20061205215503.GW44411608@melbourne.sgi.com> <457682C3.6000802@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457682C3.6000802@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 9936 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1488 Lines: 50 On Wed, Dec 06, 2006 at 08:43:47AM +0000, Lachlan McIlroy wrote: > David Chinner wrote: > >On Tue, Dec 05, 2006 at 12:46:46PM +0100, Klaus Strebel wrote: > > > >>Hi guys, > >> > >>just updated my CVS copy from oss.sgi.com ( the linux-2.6-xfs ) and > >>tried to compile ... but your patch failes to compile if HAVE_PERCPU_SB > >>is #ifndef'd :-(, the m_icsb_mutex is not in the struct see xfs_mount.h. > >>Make oldconfig didn't show HAVE_PERCPU_SB as option for .config, looks > >>like nobody tested on a single processor config ?? > > > > > >Sorry - my bad. The code did not change for UP, so I didn't think to > >test it. The patch below abstracts the icsb_mutex so that it > >doesn't get directly referenced by code outside the per-cpu counter > >code. Builds with and without HAVE_PERCPU_SB defined. > > > >I'll run a test cycle on it and get it fixed up. > > > >Cheers, > > > >Dave. > > @@ -1803,6 +1803,7 @@ xfs_icsb_destroy_counters( > unregister_hotcpu_notifier(&mp->m_icsb_notifier); > free_percpu(mp->m_sb_cnts); > } > + mutex_destroy(&mp->m_icsb_mutex); > } > > Do you need to abstract the call to mutex_destroy too? No. I didn't abstract the mutex_init and mutex_destroy calls because they are in the init/destroy functions for the icsb subsystem and those functions are #define'd out when HAVE_PERCPU_SB is not defined. > The rest of the change looks good. Thanks, Lachlan. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 7 21:41:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 21:41:44 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB85fYqw032441 for ; Thu, 7 Dec 2006 21:41:36 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA06688; Fri, 8 Dec 2006 16:40:40 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kB85ed7Y56608072; Fri, 8 Dec 2006 16:40:40 +1100 (AEDT) Received: (from bnaujok@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kB85ecW728068533; Fri, 8 Dec 2006 16:40:38 +1100 (AEDT) Date: Fri, 8 Dec 2006 16:40:38 +1100 (AEDT) From: Barry Naujok Message-Id: <200612080540.kB85ecW728068533@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 958693 - Restore xfs/list.h X-archive-position: 9937 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 960 Lines: 25 Undo rename of xfs/list.h since this is effectively part of the xfs-devel package Date: Fri Dec 8 16:40:13 AEDT 2006 Workarea: snort.melbourne.sgi.com:/home/bnaujok/isms/repair Inspected by: ,nathans@debian.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:27671a xfsprogs/VERSION - 1.168 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.168&r2=text&tr2=1.167&f=h - Bumped version to 2.8.17 xfsprogs/doc/CHANGES - 1.232 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.232&r2=text&tr2=1.231&f=h - Undo rename of xfs/list.h since this is effectively part of the xfs-devel package xfsprogs/debian/changelog - 1.148 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.148&r2=text&tr2=1.147&f=h - Update debian packaging info From owner-xfs@oss.sgi.com Thu Dec 7 21:46:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 07 Dec 2006 21:46:43 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kB85kWqw000941 for ; Thu, 7 Dec 2006 21:46:34 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA06485; Fri, 8 Dec 2006 16:33:05 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 1113) id 5136658CA5AD; Fri, 8 Dec 2006 16:33:05 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: REOPEN 958693 - Restore xfs/list.h Message-Id: <20061208053305.5136658CA5AD@chook.melbourne.sgi.com> Date: Fri, 8 Dec 2006 16:33:05 +1100 (EST) From: chatz@sgi.com (David Chatterton) X-archive-position: 9938 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@sgi.com Precedence: bulk X-list: xfs Content-Length: 619 Lines: 18 Undo rename of xfs/list.h since this is effectively part of the XFS development interface that has already shipped. Date: Fri Dec 8 16:32:10 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/chatz/isms/xfs-cmds Inspected by: bnaujok Undoes mod: master-melb:xfs-cmds:27635a The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:27668a xfsprogs/include/libxfs.h - 1.59 - changed xfsprogs/include/Makefile - 1.30 - changed xfsprogs/libxfs/cache.c - 1.9 - changed xfsprogs/include/xfs_list.h - 1.2 - renamed to xfsprogs/include/list.h 1.4 From owner-xfs@oss.sgi.com Fri Dec 8 07:45:12 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Dec 2006 07:45:18 -0800 (PST) Received: from bay0-omc1-s31.bay0.hotmail.com (bay0-omc1-s31.bay0.hotmail.com [65.54.246.103]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB8FjBqw021325 for ; Fri, 8 Dec 2006 07:45:12 -0800 Received: from BAY116-W6 ([64.4.38.106]) by bay0-omc1-s31.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 8 Dec 2006 07:32:19 -0800 X-Originating-IP: [62.252.0.9] X-Originating-Email: [dennisvarouxis@hotmail.com] Message-ID: From: Dennis Varouxis To: Subject: Unable to mount XFS partition on Sun Ultra/Linux 2.6.17 - Function not implemented Date: Fri, 8 Dec 2006 15:32:19 +0000 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2006 15:32:19.0570 (UTC) FILETIME=[0C5AFD20:01C71ADE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id kB8FjCqw021336 X-archive-position: 9939 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dennisvarouxis@hotmail.com Precedence: bulk X-list: xfs Content-Length: 3103 Lines: 105 I've got an ailing SGI which currently doesn't boot, so I plucked the disk out and slotted it into my Sun box to snoop around. Unfortunately despite my best technical and google skills I haven't been able to resolve this. Attempting to mount the main disk partition with a simple "mount -t xfs /dev/sda1 /mnt/sgidisk" yields only "mount: Function not implemented". That's it, that's all I've got. Except that I know from debugging mount that the mount syscall raises errno 90, which goes into strerror() which returns the "not implemented" message. It's a SCSI disk formatted to XFS by IRIX. IRIX and linux XFS are reportedly disk compatible so I don't see a problem there. There's a boot partition (1), a swap partition (2), and the 9 and 11 partitions used for the SGI disk label. The host system is a Sun Ultra 5 (sparc64 sun4u) with an Adaptec aix7xxx controller, running Gentoo Linux kernel 2.6.17-r8. The kernel has been built with SGI partition map support. I've got the aic7xxx and xfs drivers compiled as modules and set to autoload (I've tried with built-in versions as well and get the same result). The kernel at this point has been compiled with debug enabled and with CONFIG_XFS_DEBUG=y. The XFS driver confirms this in dmesg: "SGI XFS with ACLs, security attributes, large block/inode numbers, debug enabled SGI XFS Quota Management subsystem" However when I mount there's nothing emitted in /var/log/messages. Note the partition type says "SGI efs". However trying to mount -t efs fails with the expected "mount: wrong fs type". (EFS compiled as a module and modprobed). The output from xfs_db which admittedly doesn't mean much, to me at least, is: azrael ~ # xfs_db -c sb -c p /dev/sda1 magicnum = 0x58465342 blocksize = 4096 dblocks = 491395 rblocks = 0 rextents = 0 uuid = dbfdfd61-f556-1021-8e74-0800690ac5d3 logstart = 262148 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 61425 agcount = 8 rbmblocks = 0 logblocks = 1000 versionnum = 0x1094 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 16 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 35648 ifree = 1636 fdblocks = 164789 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 Also interesting is the output from xfs_check: "ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check." Although this indicates that the filesystems should at least be mountable. Any help would be appreciated - what am I missing? Is there somewhere else that the kernel and/or the xfs driver would log their debug messages? thanks dennis features2 = 0 _________________________________________________________________ Be one of the first to try Windows Live Mail. http://ideas.live.com/programpage.aspx?versionId=5d21c51a-b161-4314-9b0e-4911fb2b2e6d From owner-xfs@oss.sgi.com Fri Dec 8 07:57:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Dec 2006 07:57:32 -0800 (PST) Received: from talk.nabble.com (www.nabble.com [72.21.53.35]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB8FvNqw023187 for ; Fri, 8 Dec 2006 07:57:24 -0800 Received: from [72.21.53.38] (helo=jubjub.nabble.com) by talk.nabble.com with esmtp (Exim 4.50) id 1Gshqt-0002BV-Gy for linux-xfs@oss.sgi.com; Fri, 08 Dec 2006 07:41:31 -0800 Message-ID: <7759642.post@talk.nabble.com> Date: Fri, 8 Dec 2006 07:41:31 -0800 (PST) From: f1sh To: linux-xfs@oss.sgi.com Subject: Unable to mount XFS partition on Sun Ultra/Linux 2.6.17 - Function not implemented MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: dennisvarouxis@hotmail.com X-archive-position: 9940 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dennisvarouxis@hotmail.com Precedence: bulk X-list: xfs Content-Length: 3136 Lines: 110 I've got an ailing SGI which currently doesn't boot, so I plucked the disk out and slotted it into my Sun box to snoop around. Unfortunately despite my best technical and google skills I haven't been able to resolve this. Attempting to mount the main disk partition with a simple "mount -t xfs /dev/sda1 /mnt/sgidisk" yields only "mount: Function not implemented". That's it, that's all I've got. Except that I know from debugging mount that the mount syscall raises errno 90, which goes into strerror() which returns the "not implemented" message. It's a SCSI disk formatted to XFS by IRIX. IRIX and linux XFS are reportedly disk compatible so I don't see a problem there. There's a boot partition (1), a swap partition (2), and the 9 and 11 partitions used for the SGI disk label. The host system is a Sun Ultra 5 (sparc64 sun4u) with an Adaptec aix7xxx controller, running Gentoo Linux kernel 2.6.17-r8. The kernel has been built with SGI partition map support. I've got the aic7xxx and xfs drivers compiled as modules and set to autoload (I've tried with built-in versions as well and get the same result). The kernel at this point has been compiled with debug enabled and with CONFIG_XFS_DEBUG=y. The XFS driver confirms this in dmesg: "SGI XFS with ACLs, security attributes, large block/inode numbers, debug enabled SGI XFS Quota Management subsystem" However when I attempt the mount there's nothing emitted in /var/log/messages. Note the partition type says "SGI efs". However trying to mount -t efs fails with the expected "mount: wrong fs type". (EFS compiled as a module and modprobed). The output from xfs_db which admittedly doesn't mean much, to me at least, is: azrael ~ # xfs_db -c sb -c p /dev/sda1 magicnum = 0x58465342 blocksize = 4096 dblocks = 491395 rblocks = 0 rextents = 0 uuid = dbfdfd61-f556-1021-8e74-0800690ac5d3 logstart = 262148 rootino = 128 rbmino = 129 rsumino = 130 rextsize = 16 agblocks = 61425 agcount = 8 rbmblocks = 0 logblocks = 1000 versionnum = 0x1094 sectsize = 512 inodesize = 256 inopblock = 16 fname = "\000\000\000\000\000\000\000\000\000\000\000\000" blocklog = 12 sectlog = 9 inodelog = 8 inopblog = 4 agblklog = 16 rextslog = 0 inprogress = 0 imax_pct = 25 icount = 35648 ifree = 1636 fdblocks = 164789 frextents = 0 uquotino = 0 gquotino = 0 qflags = 0 flags = 0 shared_vn = 0 inoalignmt = 2 unit = 0 width = 0 dirblklog = 0 logsectlog = 0 logsectsize = 0 logsunit = 0 features2 = 0 Also interesting is the output from xfs_check: "ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_check." Although this indicates that the filesystems should at least be mountable. Any help would be appreciated - what am I missing? Is there somewhere else that the kernel and/or the xfs driver would log their debug messages? thanks dennis -- View this message in context: http://www.nabble.com/Unable-to-mount-XFS-partition-on-Sun-Ultra-Linux-2.6.17---Function-not-implemented-tf2781318.html#a7759642 Sent from the linux-xfs mailing list archive at Nabble.com. From owner-xfs@oss.sgi.com Fri Dec 8 08:51:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Dec 2006 08:51:41 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB8GpYqw001282 for ; Fri, 8 Dec 2006 08:51:36 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 2B33618E20C61; Fri, 8 Dec 2006 10:50:43 -0600 (CST) Message-ID: <457997E6.60900@sandeen.net> Date: Fri, 08 Dec 2006 10:50:46 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Dennis Varouxis CC: xfs@oss.sgi.com Subject: Re: Unable to mount XFS partition on Sun Ultra/Linux 2.6.17 - Function not implemented References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9942 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 801 Lines: 27 Dennis Varouxis wrote: > The output from xfs_db which admittedly doesn't mean much, to me at least, is: > > azrael ~ # xfs_db -c sb -c p /dev/sda1 ... > logblocks = 1000 > versionnum = 0x1094 Looks like version one directories, recently ripped out of Linux... Try an older kernel... can't recall exactly when this changed, but you can probably find it in the archives, search "dirv1" I think. > Also interesting is the output from xfs_check: > > "ERROR: The filesystem has valuable metadata changes in a log which needs to > be replayed. Mount the filesystem to replay the log, and unmount it before > re-running xfs_check." Linux can't replay irix logs, you could zero out the log with xfs_repair -L, or, less destructively, mount with -o ro,norecovery and see what you can get. -Eric From owner-xfs@oss.sgi.com Fri Dec 8 08:51:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Dec 2006 08:51:23 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB8GpFqw001207 for ; Fri, 8 Dec 2006 08:51:16 -0800 Received: from [134.15.160.35] (vpn-emea-sw-emea-160-35.emea.sgi.com [134.15.160.35]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kB8GoEbj63532456; Fri, 8 Dec 2006 08:50:15 -0800 (PST) Message-ID: <457997C6.4010307@sgi.com> Date: Fri, 08 Dec 2006 16:50:14 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nscott@aconex.com CC: bnaujok@sgi.com, chatz@sgi.com, xfs@oss.sgi.com Subject: Re: [PATCH] fix compiler warnings References: <1165535828.30459.42.camel@edge> In-Reply-To: <1165535828.30459.42.camel@edge> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 9941 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 47002 Lines: 930 Barry, I see you've already checked this in (good thing I checked before reviewing the changes). Did you send a TAKE for this? Nathan Scott wrote: > The xfsprogs userspace builds have been generating hundreds of > warnings with recent gcc versions for some time, due to the > char signedness inconsistencies we have in places. Here's a > patch to clean that up, so we can at least see the interesting > warnings cropping up now. > > cheers. > > > > ------------------------------------------------------------------------ > > util.c: In function 'libxfs_dir_bogus_removename': > util.c:470: warning: pointer targets in assignment differ in signedness > util.c: In function 'libxfs_dir2_bogus_removename': > util.c:531: warning: pointer targets in assignment differ in signedness > > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir.c -fPIC -DPIC -o .libs/xfs_dir.o > xfs_dir.c: In function 'xfs_dir_startup': > xfs_dir.c:36: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir.c:37: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir.c: In function 'libxfs_dir_createname': > xfs_dir.c:118: warning: pointer targets in assignment differ in signedness > xfs_dir.c:120: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir.c: In function 'libxfs_dir_removename': > xfs_dir.c:180: warning: pointer targets in assignment differ in signedness > xfs_dir.c:182: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir.c: In function 'libxfs_dir_lookup': > xfs_dir.c:224: warning: pointer targets in assignment differ in signedness > xfs_dir.c:226: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir.c: In function 'libxfs_dir_replace': > xfs_dir.c:269: warning: pointer targets in assignment differ in signedness > xfs_dir.c:271: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir_leaf.c -fPIC -DPIC -o .libs/xfs_dir_leaf.o > xfs_dir_leaf.c: In function 'libxfs_dir_shortform_to_leaf': > xfs_dir_leaf.c:290: warning: pointer targets in assignment differ in signedness > xfs_dir_leaf.c:306: warning: pointer targets in assignment differ in signedness > xfs_dir_leaf.c:316: warning: pointer targets in assignment differ in signedness > xfs_dir_leaf.c:319: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir_leaf.c: In function 'xfs_dir_leaf_to_shortform': > xfs_dir_leaf.c:452: warning: pointer targets in assignment differ in signedness > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir2.c -fPIC -DPIC -o .libs/xfs_dir2.o > xfs_dir2.c: In function 'libxfs_dir2_createname': > xfs_dir2.c:99: warning: pointer targets in assignment differ in signedness > xfs_dir2.c:101: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2.c: In function 'libxfs_dir2_lookup': > xfs_dir2.c:150: warning: pointer targets in assignment differ in signedness > xfs_dir2.c:152: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2.c: In function 'libxfs_dir2_removename': > xfs_dir2.c:207: warning: pointer targets in assignment differ in signedness > xfs_dir2.c:209: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2.c: In function 'libxfs_dir2_replace': > xfs_dir2.c:262: warning: pointer targets in assignment differ in signedness > xfs_dir2.c:264: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_attr_leaf.c -fPIC -DPIC -o .libs/xfs_attr_leaf.o > xfs_attr_leaf.c: In function 'xfs_attr_shortform_to_leaf': > xfs_attr_leaf.c:375: warning: pointer targets in assignment differ in signedness > xfs_attr_leaf.c:377: warning: pointer targets in assignment differ in signedness > xfs_attr_leaf.c:380: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_attr_leaf.c: In function 'xfs_attr_leaf_to_shortform': > xfs_attr_leaf.c:513: warning: pointer targets in assignment differ in signedness > xfs_attr_leaf.c:515: warning: pointer targets in assignment differ in signedness > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir2_block.c -fPIC -DPIC -o .libs/xfs_dir2_block.o > xfs_dir2_block.c: In function 'libxfs_dir2_sf_to_block': > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > xfs_dir2_block.c:1049: warning: pointer targets in passing argument 1 of 'libxfs_da_hashname' differ in signedness > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c xfs_attr.c -fPIC -DPIC -o .libs/xfs_attr.o > xfs_attr.c: In function 'libxfs_attr_set_int': > xfs_attr.c:106: warning: pointer targets in assignment differ in signedness > xfs_attr.c:108: warning: pointer targets in assignment differ in signedness > xfs_attr.c: In function 'libxfs_attr_remove_int': > xfs_attr.c:316: warning: pointer targets in assignment differ in signedness > xfs_attr.c: In function 'xfs_attr_rmtval_set': > xfs_attr.c:1292: warning: pointer targets in assignment differ in signedness > gcc -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -c fstype.c -fPIC -DPIC -o .libs/fstype.o > fstype.c: In function 'is_reiserfs_magic_string': > fstype.c:158: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:158: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:158: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:158: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:158: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:158: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:158: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:158: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:160: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:160: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:160: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:160: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:160: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:160: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:160: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:160: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c: In function 'fstype': > fstype.c:222: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:222: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:222: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:222: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:222: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:222: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:222: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:222: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:228: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:228: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:228: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:228: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:228: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:228: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:228: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:228: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:234: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:234: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:234: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:234: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:234: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:234: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:234: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:234: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:235: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:235: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:235: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:235: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:235: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:235: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:235: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:235: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:236: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:236: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:236: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:236: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:236: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:237: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:237: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:237: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:237: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:237: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:237: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:237: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:237: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:238: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:238: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:238: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:238: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:238: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:238: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:238: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:238: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:241: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:241: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:241: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:241: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:241: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:241: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:241: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:241: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:242: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:242: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:242: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:242: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:242: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:242: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:242: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:242: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:243: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:243: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:243: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:243: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:243: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:243: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:243: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:243: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > fstype.c:244: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:244: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:244: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:244: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness > fstype.c:244: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:244: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:244: warning: pointer targets in passing argument 1 of '__builtin_strcmp' differ in signedness > fstype.c:244: warning: pointer targets in passing argument 1 of 'strncmp' differ in signedness > > gcc -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -DENABLE_READLINE -c -o check.o check.c > check.c: In function ‘process_data_dir_v2’: > check.c:2302: warning: pointer targets in passing argument 1 of ‘libxfs_da_hashname’ differ in signedness > > gcc -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -funsigned-char -fno-strict-aliasing -Wall -DENABLE_READLINE -c -o hash.o hash.c > hash.c: In function ‘hash_f’: > hash.c:55: warning: pointer targets in passing argument 1 of ‘libxfs_da_hashname’ differ in signedness > > phase6.c: In function ‘dir_bogus_removename’: > phase6.c:391: warning: pointer targets in passing argument 3 of ‘libxfs_dir2_bogus_removename’ differ in signedness > phase6.c:394: warning: pointer targets in passing argument 3 of ‘libxfs_dir_bogus_removename’ differ in signedness > phase6.c: At top level: > phase6.c:375: warning: ‘dir_removename’ defined but not used > Index: xfsprogs/libxfs/util.c > =================================================================== > --- xfsprogs.orig/libxfs/util.c 2006-12-08 09:25:43.471005750 +1100 > +++ xfsprogs/libxfs/util.c 2006-12-08 09:26:31.165986500 +1100 > @@ -452,7 +452,7 @@ libxfs_bmap_next_offset( > * This was originally in the kernel, but only used in xfs_repair. > */ > int > -xfs_dir_bogus_removename(xfs_trans_t *trans, xfs_inode_t *dp, char *name, > +xfs_dir_bogus_removename(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, > xfs_fsblock_t *firstblock, xfs_bmap_free_t *flist, > xfs_extlen_t total, xfs_dahash_t hashval, int namelen) > { > @@ -510,7 +510,7 @@ int > xfs_dir2_bogus_removename( > xfs_trans_t *tp, /* transaction pointer */ > xfs_inode_t *dp, /* incore directory inode */ > - char *name, /* name of entry to remove */ > + uchar_t *name, /* name of entry to remove */ > xfs_fsblock_t *first, /* bmap's firstblock */ > xfs_bmap_free_t *flist, /* bmap's freeblock list */ > xfs_extlen_t total, /* bmap's total block count */ > Index: xfsprogs/include/libxfs.h > =================================================================== > --- xfsprogs.orig/include/libxfs.h 2006-12-08 09:25:43.547010500 +1100 > +++ xfsprogs/include/libxfs.h 2006-12-08 09:26:31.165986500 +1100 > @@ -429,33 +429,33 @@ extern void libxfs_dir_mount (xfs_mount_ > extern void libxfs_dir2_mount (xfs_mount_t *); > extern int libxfs_dir_init (xfs_trans_t *, xfs_inode_t *, xfs_inode_t *); > extern int libxfs_dir2_init (xfs_trans_t *, xfs_inode_t *, xfs_inode_t *); > -extern int libxfs_dir_createname (xfs_trans_t *, xfs_inode_t *, char *, > +extern int libxfs_dir_createname (xfs_trans_t *, xfs_inode_t *, uchar_t *, > int, xfs_ino_t, xfs_fsblock_t *, > xfs_bmap_free_t *, xfs_extlen_t); > -extern int libxfs_dir2_createname (xfs_trans_t *, xfs_inode_t *, char *, > +extern int libxfs_dir2_createname (xfs_trans_t *, xfs_inode_t *, uchar_t *, > int, xfs_ino_t, xfs_fsblock_t *, > xfs_bmap_free_t *, xfs_extlen_t); > extern int libxfs_dir_lookup (xfs_trans_t *, xfs_inode_t *, > - char *, int, xfs_ino_t *); > + uchar_t *, int, xfs_ino_t *); > extern int libxfs_dir2_lookup (xfs_trans_t *, xfs_inode_t *, > - char *, int, xfs_ino_t *); > + uchar_t *, int, xfs_ino_t *); > extern int libxfs_dir_replace (xfs_trans_t *, xfs_inode_t *, > - char *, int, xfs_ino_t, xfs_fsblock_t *, > + uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, > xfs_bmap_free_t *, xfs_extlen_t); > extern int libxfs_dir2_replace (xfs_trans_t *, xfs_inode_t *, > - char *, int, xfs_ino_t, xfs_fsblock_t *, > + uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, > xfs_bmap_free_t *, xfs_extlen_t); > extern int libxfs_dir_removename (xfs_trans_t *, xfs_inode_t *, > - char *, int, xfs_ino_t, xfs_fsblock_t *, > + uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, > xfs_bmap_free_t *, xfs_extlen_t); > extern int libxfs_dir2_removename (xfs_trans_t *, xfs_inode_t *, > - char *, int, xfs_ino_t, xfs_fsblock_t *, > + uchar_t *, int, xfs_ino_t, xfs_fsblock_t *, > xfs_bmap_free_t *, xfs_extlen_t); > extern int libxfs_dir_bogus_removename (xfs_trans_t *, xfs_inode_t *, > - char *, xfs_fsblock_t *, xfs_bmap_free_t *, > + uchar_t *, xfs_fsblock_t *, xfs_bmap_free_t *, > xfs_extlen_t, xfs_dahash_t, int); > extern int libxfs_dir2_bogus_removename (xfs_trans_t *, xfs_inode_t *, > - char *, xfs_fsblock_t *, xfs_bmap_free_t *, > + uchar_t *, xfs_fsblock_t *, xfs_bmap_free_t *, > xfs_extlen_t, xfs_dahash_t, int); > > > Index: xfsprogs/libxfs/xfs_dir.c > =================================================================== > --- xfsprogs.orig/libxfs/xfs_dir.c 2006-12-08 09:25:43.479006250 +1100 > +++ xfsprogs/libxfs/xfs_dir.c 2006-12-08 09:26:31.165986500 +1100 > @@ -33,8 +33,8 @@ xfs_dahash_t xfs_dir_hash_dot, xfs_dir_h > void > xfs_dir_startup(void) > { > - xfs_dir_hash_dot = xfs_da_hashname(".", 1); > - xfs_dir_hash_dotdot = xfs_da_hashname("..", 2); > + xfs_dir_hash_dot = xfs_da_hashname((const uchar_t *) ".", 1); > + xfs_dir_hash_dotdot = xfs_da_hashname((const uchar_t *) "..", 2); > } > > /* > @@ -99,7 +99,7 @@ xfs_dir_init(xfs_trans_t *trans, xfs_ino > * Transitions directory from shortform to Btree as necessary. > */ > STATIC int /* error */ > -xfs_dir_createname(xfs_trans_t *trans, xfs_inode_t *dp, char *name, > +xfs_dir_createname(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, > int namelen, xfs_ino_t inum, xfs_fsblock_t *firstblock, > xfs_bmap_free_t *flist, xfs_extlen_t total) > { > @@ -165,7 +165,7 @@ xfs_dir_createname(xfs_trans_t *trans, x > * Transitions directory from Btree to shortform as necessary. > */ > STATIC int /* error */ > -xfs_dir_removename(xfs_trans_t *trans, xfs_inode_t *dp, char *name, > +xfs_dir_removename(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, > int namelen, xfs_ino_t ino, xfs_fsblock_t *firstblock, > xfs_bmap_free_t *flist, xfs_extlen_t total) > { > @@ -209,7 +209,7 @@ xfs_dir_removename(xfs_trans_t *trans, x > } > > STATIC int /* error */ > -xfs_dir_lookup(xfs_trans_t *trans, xfs_inode_t *dp, char *name, int namelen, > +xfs_dir_lookup(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, int namelen, > xfs_ino_t *inum) > { > xfs_da_args_t args; > @@ -251,7 +251,7 @@ xfs_dir_lookup(xfs_trans_t *trans, xfs_i > } > > STATIC int /* error */ > -xfs_dir_replace(xfs_trans_t *trans, xfs_inode_t *dp, char *name, int namelen, > +xfs_dir_replace(xfs_trans_t *trans, xfs_inode_t *dp, uchar_t *name, int namelen, > xfs_ino_t inum, xfs_fsblock_t *firstblock, > xfs_bmap_free_t *flist, xfs_extlen_t total) > { > Index: xfsprogs/libxfs/xfs_dir2.c > =================================================================== > --- xfsprogs.orig/libxfs/xfs_dir2.c 2006-12-08 09:25:43.527009250 +1100 > +++ xfsprogs/libxfs/xfs_dir2.c 2006-12-08 09:26:31.165986500 +1100 > @@ -77,7 +77,7 @@ STATIC int /* error */ > xfs_dir2_createname( > xfs_trans_t *tp, /* transaction pointer */ > xfs_inode_t *dp, /* incore directory inode */ > - char *name, /* new entry name */ > + uchar_t *name, /* new entry name */ > int namelen, /* new entry name length */ > xfs_ino_t inum, /* new entry inode number */ > xfs_fsblock_t *first, /* bmap's firstblock */ > @@ -133,7 +133,7 @@ STATIC int /* error */ > xfs_dir2_lookup( > xfs_trans_t *tp, /* transaction pointer */ > xfs_inode_t *dp, /* incore directory inode */ > - char *name, /* lookup name */ > + uchar_t *name, /* lookup name */ > int namelen, /* lookup name length */ > xfs_ino_t *inum) /* out: inode number */ > { > @@ -188,7 +188,7 @@ STATIC int /* error */ > xfs_dir2_removename( > xfs_trans_t *tp, /* transaction pointer */ > xfs_inode_t *dp, /* incore directory inode */ > - char *name, /* name of entry to remove */ > + uchar_t *name, /* name of entry to remove */ > int namelen, /* name length of entry to remove */ > xfs_ino_t ino, /* inode number of entry to remove */ > xfs_fsblock_t *first, /* bmap's firstblock */ > @@ -240,7 +240,7 @@ STATIC int /* error */ > xfs_dir2_replace( > xfs_trans_t *tp, /* transaction pointer */ > xfs_inode_t *dp, /* incore directory inode */ > - char *name, /* name of entry to replace */ > + uchar_t *name, /* name of entry to replace */ > int namelen, /* name length of entry to replace */ > xfs_ino_t inum, /* new inode number */ > xfs_fsblock_t *first, /* bmap's firstblock */ > Index: xfsprogs/libxfs/xfs_dir_leaf.c > =================================================================== > --- xfsprogs.orig/libxfs/xfs_dir_leaf.c 2006-12-08 09:25:43.503007750 +1100 > +++ xfsprogs/libxfs/xfs_dir_leaf.c 2006-12-08 09:26:31.165986500 +1100 > @@ -287,7 +287,7 @@ xfs_dir_shortform_to_leaf(xfs_da_args_t > goto out; > xfs_da_buf_done(bp); > > - args.name = "."; > + args.name = (const uchar_t *) "."; > args.namelen = 1; > args.hashval = xfs_dir_hash_dot; > args.inumber = dp->i_ino; > @@ -303,7 +303,7 @@ xfs_dir_shortform_to_leaf(xfs_da_args_t > if (retval) > goto out; > > - args.name = ".."; > + args.name = (const uchar_t *) ".."; > args.namelen = 2; > args.hashval = xfs_dir_hash_dotdot; > args.inumber = inumber; > @@ -313,9 +313,9 @@ xfs_dir_shortform_to_leaf(xfs_da_args_t > > sfe = &sf->list[0]; > for (i = 0; i < INT_GET(sf->hdr.count, ARCH_CONVERT); i++) { > - args.name = (char *)(sfe->name); > + args.name = (const uchar_t *)(sfe->name); > args.namelen = sfe->namelen; > - args.hashval = xfs_da_hashname((char *)(sfe->name), > + args.hashval = xfs_da_hashname((const uchar_t *)(sfe->name), > sfe->namelen); > XFS_DIR_SF_GET_DIRINO(&sfe->inumber, &args.inumber); > retval = xfs_dir_leaf_addname(&args); > @@ -449,7 +449,7 @@ xfs_dir_leaf_to_shortform(xfs_da_args_t > if (!entry->nameidx) > continue; > namest = XFS_DIR_LEAF_NAMESTRUCT(leaf, INT_GET(entry->nameidx, ARCH_CONVERT)); > - args.name = (char *)(namest->name); > + args.name = (const uchar_t *)(namest->name); > args.namelen = entry->namelen; > args.hashval = INT_GET(entry->hashval, ARCH_CONVERT); > XFS_DIR_SF_GET_DIRINO(&namest->inumber, &args.inumber); > Index: xfsprogs/libxfs/xfs_attr_leaf.c > =================================================================== > --- xfsprogs.orig/libxfs/xfs_attr_leaf.c 2006-12-08 09:25:43.539010000 +1100 > +++ xfsprogs/libxfs/xfs_attr_leaf.c 2006-12-08 09:26:31.169986750 +1100 > @@ -372,11 +372,11 @@ xfs_attr_shortform_to_leaf(xfs_da_args_t > > sfe = &sf->list[0]; > for (i = 0; i < INT_GET(sf->hdr.count, ARCH_CONVERT); i++) { > - nargs.name = (char *)sfe->nameval; > + nargs.name = (const uchar_t *)sfe->nameval; > nargs.namelen = sfe->namelen; > - nargs.value = (char *)&sfe->nameval[nargs.namelen]; > + nargs.value = (uchar_t *)&sfe->nameval[nargs.namelen]; > nargs.valuelen = INT_GET(sfe->valuelen, ARCH_CONVERT); > - nargs.hashval = xfs_da_hashname((char *)sfe->nameval, > + nargs.hashval = xfs_da_hashname((const uchar_t *)sfe->nameval, > sfe->namelen); > nargs.flags = (sfe->flags & XFS_ATTR_SECURE) ? ATTR_SECURE : > ((sfe->flags & XFS_ATTR_ROOT) ? ATTR_ROOT : 0); > @@ -510,9 +510,9 @@ xfs_attr_leaf_to_shortform(xfs_dabuf_t * > continue; > ASSERT(entry->flags & XFS_ATTR_LOCAL); > name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); > - nargs.name = (char *)name_loc->nameval; > + nargs.name = (const uchar_t *)name_loc->nameval; > nargs.namelen = name_loc->namelen; > - nargs.value = (char *)&name_loc->nameval[nargs.namelen]; > + nargs.value = (uchar_t *)&name_loc->nameval[nargs.namelen]; > nargs.valuelen = INT_GET(name_loc->valuelen, ARCH_CONVERT); > nargs.hashval = INT_GET(entry->hashval, ARCH_CONVERT); > nargs.flags = (entry->flags & XFS_ATTR_SECURE) ? ATTR_SECURE : > Index: xfsprogs/libxfs/xfs_attr.c > =================================================================== > --- xfsprogs.orig/libxfs/xfs_attr.c 2006-12-08 09:27:45.790650250 +1100 > +++ xfsprogs/libxfs/xfs_attr.c 2006-12-08 09:30:15.307994500 +1100 > @@ -103,9 +103,9 @@ xfs_attr_set_int(xfs_inode_t *dp, const > * Fill in the arg structure for this request. > */ > memset((char *)&args, 0, sizeof(args)); > - args.name = name; > + args.name = (const uchar_t *)name; > args.namelen = namelen; > - args.value = value; > + args.value = (uchar_t *)value; > args.valuelen = valuelen; > args.flags = flags; > args.hashval = xfs_da_hashname(args.name, args.namelen); > @@ -313,7 +313,7 @@ xfs_attr_remove_int(xfs_inode_t *dp, con > * Fill in the arg structure for this request. > */ > memset((char *)&args, 0, sizeof(args)); > - args.name = name; > + args.name = (const uchar_t *)name; > args.namelen = namelen; > args.flags = flags; > args.hashval = xfs_da_hashname(args.name, args.namelen); > @@ -1289,7 +1289,7 @@ xfs_attr_rmtval_set(xfs_da_args_t *args) > > dp = args->dp; > mp = dp->i_mount; > - src = args->value; > + src = (xfs_caddr_t)args->value; > > /* > * Find a "hole" in the attribute address space large enough for > Index: xfsprogs/libxfs/xfs_dir2_block.c > =================================================================== > --- xfsprogs.orig/libxfs/xfs_dir2_block.c 2006-12-08 09:26:53.483381250 +1100 > +++ xfsprogs/libxfs/xfs_dir2_block.c 2006-12-08 09:27:10.736459500 +1100 > @@ -1046,7 +1046,7 @@ xfs_dir2_sf_to_block( > tagp = XFS_DIR2_DATA_ENTRY_TAG_P(dep); > INT_SET(*tagp, ARCH_CONVERT, (xfs_dir2_data_off_t)((char *)dep - (char *)block)); > xfs_dir2_data_log_entry(tp, bp, dep); > - INT_SET(blp[2 + i].hashval, ARCH_CONVERT, xfs_da_hashname((char *)sfep->name, sfep->namelen)); > + INT_SET(blp[2 + i].hashval, ARCH_CONVERT, xfs_da_hashname((const uchar_t *)sfep->name, sfep->namelen)); > INT_SET(blp[2 + i].address, ARCH_CONVERT, XFS_DIR2_BYTE_TO_DATAPTR(mp, > (char *)dep - (char *)block)); > offset = (int)((char *)(tagp + 1) - (char *)block); > Index: xfsprogs/libdisk/fstype.c > =================================================================== > --- xfsprogs.orig/libdisk/fstype.c 2006-12-08 09:50:20.955342750 +1100 > +++ xfsprogs/libdisk/fstype.c 2006-12-08 09:50:27.711765000 +1100 > @@ -141,11 +141,11 @@ may_be_swap(const char *s) { > > /* rather weak necessary condition */ > static int > -may_be_adfs(const u_char *s) { > - u_char *p; > +may_be_adfs(const char *s) { > + char *p; > int sum; > > - p = (u_char *) s + 511; > + p = (char *) s + 511; > sum = 0; > while(--p != s) > sum = (sum >> 8) + (sum & 0xff) + *p; > @@ -301,7 +301,7 @@ fstype(const char *device) { > goto io_error; > > /* only a weak test */ > - if (may_be_adfs((u_char *) &adfssb) > + if (may_be_adfs((char *) &adfssb) > && (adfsblksize(adfssb) >= 8 && > adfsblksize(adfssb) <= 10)) > type = "adfs"; > Index: xfsprogs/libdisk/fstype.h > =================================================================== > --- xfsprogs.orig/libdisk/fstype.h 2006-12-08 09:49:45.061099500 +1100 > +++ xfsprogs/libdisk/fstype.h 2006-12-08 09:51:00.657824000 +1100 > @@ -38,8 +38,8 @@ > #define MINIX2_SUPER_MAGIC 0x2468 /* minix v2, 14 char names */ > #define MINIX2_SUPER_MAGIC2 0x2478 /* minix v2, 30 char names */ > struct minix_super_block { > - u_char s_dummy[16]; > - u_char s_magic[2]; > + char s_dummy[16]; > + char s_magic[2]; > }; > #define minixmagic(s) assemble2le(s.s_magic) > > @@ -63,8 +63,8 @@ struct hs_volume_descriptor { > > #define EXT_SUPER_MAGIC 0x137D > struct ext_super_block { > - u_char s_dummy[56]; > - u_char s_magic[2]; > + char s_dummy[56]; > + char s_magic[2]; > }; > #define extmagic(s) assemble2le(s.s_magic) > > @@ -72,37 +72,37 @@ struct ext_super_block { > #define EXT2_SUPER_MAGIC 0xEF53 > #define EXT3_FEATURE_COMPAT_HAS_JOURNAL 0x0004 > struct ext2_super_block { > - u_char s_dummy1[56]; > - u_char s_magic[2]; > - u_char s_dummy2[34]; > - u_char s_feature_compat[4]; > - u_char s_feature_incompat[4]; > - u_char s_feature_ro_compat[4]; > - u_char s_uuid[16]; > - u_char s_volume_name[16]; > - u_char s_dummy3[88]; > - u_char s_journal_inum[4]; /* ext3 only */ > + char s_dummy1[56]; > + char s_magic[2]; > + char s_dummy2[34]; > + char s_feature_compat[4]; > + char s_feature_incompat[4]; > + char s_feature_ro_compat[4]; > + char s_uuid[16]; > + char s_volume_name[16]; > + char s_dummy3[88]; > + char s_journal_inum[4]; /* ext3 only */ > }; > #define ext2magic(s) assemble2le(s.s_magic) > > struct reiserfs_super_block > { > - u_char s_block_count[4]; > - u_char s_free_blocks[4]; > - u_char s_root_block[4]; > - u_char s_journal_block[4]; > - u_char s_journal_dev[4]; > - u_char s_orig_journal_size[4]; > - u_char s_journal_trans_max[4]; > - u_char s_journal_block_count[4]; > - u_char s_journal_max_batch[4]; > - u_char s_journal_max_commit_age[4]; > - u_char s_journal_max_trans_age[4]; > - u_char s_blocksize[2]; > - u_char s_oid_maxsize[2]; > - u_char s_oid_cursize[2]; > - u_char s_state[2]; > - u_char s_magic[12]; > + char s_block_count[4]; > + char s_free_blocks[4]; > + char s_root_block[4]; > + char s_journal_block[4]; > + char s_journal_dev[4]; > + char s_orig_journal_size[4]; > + char s_journal_trans_max[4]; > + char s_journal_block_count[4]; > + char s_journal_max_batch[4]; > + char s_journal_max_commit_age[4]; > + char s_journal_max_trans_age[4]; > + char s_blocksize[2]; > + char s_oid_maxsize[2]; > + char s_oid_cursize[2]; > + char s_state[2]; > + char s_magic[12]; > }; > #define REISERFS_SUPER_MAGIC_STRING "ReIsErFs" > #define REISER2FS_SUPER_MAGIC_STRING "ReIsEr2Fs" > @@ -112,9 +112,9 @@ struct reiserfs_super_block > > #define _XIAFS_SUPER_MAGIC 0x012FD16D > struct xiafs_super_block { > - u_char s_boot_segment[512]; /* 1st sector reserved for boot */ > - u_char s_dummy[60]; > - u_char s_magic[4]; > + char s_boot_segment[512]; /* 1st sector reserved for boot */ > + char s_dummy[60]; > + char s_magic[4]; > }; > #define xiafsmagic(s) assemble4le(s.s_magic) > > @@ -122,16 +122,16 @@ struct xiafs_super_block { > #define UFS_SUPER_MAGIC_LE 0x00011954 > #define UFS_SUPER_MAGIC_BE 0x54190100 > struct ufs_super_block { > - u_char s_dummy[0x55c]; > - u_char s_magic[4]; > + char s_dummy[0x55c]; > + char s_magic[4]; > }; > #define ufsmagic(s) assemble4le(s.s_magic) > > /* From Richard.Russon@ait.co.uk Wed Feb 24 08:05:27 1999 */ > #define NTFS_SUPER_MAGIC "NTFS" > struct ntfs_super_block { > - u_char s_dummy[3]; > - u_char s_magic[4]; > + char s_dummy[3]; > + char s_magic[4]; > }; > > /* From inspection of a few FAT filesystems - aeb */ > @@ -139,33 +139,33 @@ struct ntfs_super_block { > it looks like a primary has some directory entries where the extended > has a partition table: IO.SYS, MSDOS.SYS, WINBOOT.SYS */ > struct fat_super_block { > - u_char s_dummy[3]; > - u_char s_os[8]; /* "MSDOS5.0" or "MSWIN4.0" or "MSWIN4.1" */ > + char s_dummy[3]; > + char s_os[8]; /* "MSDOS5.0" or "MSWIN4.0" or "MSWIN4.1" */ > /* mtools-3.9.4 writes "MTOOL394" */ > - u_char s_dummy2[32]; > - u_char s_label[11]; /* for DOS? */ > - u_char s_fs[8]; /* "FAT12 " or "FAT16 " or all zero */ > + char s_dummy2[32]; > + char s_label[11]; /* for DOS? */ > + char s_fs[8]; /* "FAT12 " or "FAT16 " or all zero */ > /* OS/2 BM has "FAT " here. */ > - u_char s_dummy3[9]; > - u_char s_label2[11]; /* for Windows? */ > - u_char s_fs2[8]; /* garbage or "FAT32 " */ > + char s_dummy3[9]; > + char s_label2[11]; /* for Windows? */ > + char s_fs2[8]; /* garbage or "FAT32 " */ > }; > > #define XFS_SUPER_MAGIC "XFSB" > struct xfs_super_block { > - u_char s_magic[4]; > - u_char s_dummy[28]; > - u_char s_uuid[16]; > - u_char s_dummy2[60]; > - u_char s_fname[12]; > + char s_magic[4]; > + char s_dummy[28]; > + char s_uuid[16]; > + char s_dummy2[60]; > + char s_fname[12]; > }; > > #define CRAMFS_SUPER_MAGIC 0x28cd3d45 > #define CRAMFS_SUPER_MAGIC_BE 0x453dcd28 > struct cramfs_super_block { > - u_char s_magic[4]; > - u_char s_dummy[12]; > - u_char s_id[16]; > + char s_magic[4]; > + char s_dummy[12]; > + char s_id[16]; > }; > #define cramfsmagic(s) assemble4le(s.s_magic) > > @@ -173,81 +173,81 @@ struct cramfs_super_block { > #define HFSPLUS_SUPER_MAGIC 0x482B > #define HFSPLUS_SUPER_VERSION 0x004 > struct hfs_super_block { > - u_char s_magic[2]; > - u_char s_version[2]; > + char s_magic[2]; > + char s_version[2]; > }; > #define hfsmagic(s) assemble2le(s.s_magic) > #define hfsversion(s) assemble2le(s.s_version) > > #define HPFS_SUPER_MAGIC 0xf995e849 > struct hpfs_super_block { > - u_char s_magic[4]; > - u_char s_magic2[4]; > + char s_magic[4]; > + char s_magic2[4]; > }; > #define hpfsmagic(s) assemble4le(s.s_magic) > > struct adfs_super_block { > - u_char s_dummy[448]; > - u_char s_blksize[1]; > - u_char s_dummy2[62]; > - u_char s_checksum[1]; > + char s_dummy[448]; > + char s_blksize[1]; > + char s_dummy2[62]; > + char s_checksum[1]; > }; > #define adfsblksize(s) ((uint) s.s_blksize[0]) > > /* found in first 4 bytes of block 1 */ > struct vxfs_super_block { > - u_char s_magic[4]; > + char s_magic[4]; > }; > #define vxfsmagic(s) assemble4le(s.s_magic) > #define VXFS_SUPER_MAGIC 0xa501FCF5 > > struct jfs_super_block { > char s_magic[4]; > - u_char s_version[4]; > - u_char s_dummy1[93]; > + char s_version[4]; > + char s_dummy1[93]; > char s_fpack[11]; > - u_char s_dummy2[24]; > - u_char s_uuid[16]; > + char s_dummy2[24]; > + char s_uuid[16]; > char s_label[16]; > }; > #define JFS_SUPER1_OFF 0x8000 > #define JFS_MAGIC "JFS1" > > struct sysv_super_block { > - u_char s_dummy1[504]; > - u_char s_magic[4]; > - u_char type[4]; > + char s_dummy1[504]; > + char s_magic[4]; > + char type[4]; > }; > #define sysvmagic(s) assemble4le(s.s_magic) > #define SYSV_SUPER_MAGIC 0xfd187e20 > > struct mdp_super_block { > - u_char md_magic[4]; > + char md_magic[4]; > }; > #define MD_SB_MAGIC 0xa92b4efc > #define mdsbmagic(s) assemble4le(s.md_magic) > > struct ocfs_volume_header { > - u_char minor_version[4]; > - u_char major_version[4]; > - u_char signature[128]; > + char minor_version[4]; > + char major_version[4]; > + char signature[128]; > }; > > struct ocfs_volume_label { > - u_char disk_lock[48]; > - u_char label[64]; > - u_char label_len[2]; > + char disk_lock[48]; > + char label[64]; > + char label_len[2]; > }; > > #define ocfslabellen(o) assemble2le(o.label_len) > #define OCFS_MAGIC "OracleCFS" > > static inline int > -assemble2le(unsigned char *p) { > +assemble2le(char *p) { > return (p[0] | (p[1] << 8)); > } > > static inline int > -assemble4le(unsigned char *p) { > +assemble4le(char *p) { > return (p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24)); > } > Index: xfsprogs/db/check.c > =================================================================== > --- xfsprogs.orig/db/check.c 2006-12-08 09:55:43.307488500 +1100 > +++ xfsprogs/db/check.c 2006-12-08 09:55:51.732015000 +1100 > @@ -2299,7 +2299,7 @@ process_data_dir_v2( > tag_err += INT_GET(*tagp, ARCH_CONVERT) != (char *)dep - (char *)data; > addr = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, db, > (char *)dep - (char *)data); > - hash = libxfs_da_hashname((char *)dep->name, dep->namelen); > + hash = libxfs_da_hashname((uchar_t *)dep->name, dep->namelen); > dir_hash_add(hash, addr); > ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); > count++; > Index: xfsprogs/db/hash.c > =================================================================== > --- xfsprogs.orig/db/hash.c 2006-12-08 09:56:12.929339750 +1100 > +++ xfsprogs/db/hash.c 2006-12-08 09:56:25.478124000 +1100 > @@ -52,7 +52,7 @@ hash_f( > { > xfs_dahash_t hashval; > > - hashval = libxfs_da_hashname(argv[1], (int)strlen(argv[1])); > + hashval = libxfs_da_hashname((uchar_t *)argv[1], (int)strlen(argv[1])); > dbprintf("0x%x\n", hashval); > return 0; > } > Index: xfsprogs/mkfs/proto.c > =================================================================== > --- xfsprogs.orig/mkfs/proto.c 2006-12-08 09:57:08.404806750 +1100 > +++ xfsprogs/mkfs/proto.c 2006-12-08 09:58:06.060410000 +1100 > @@ -313,10 +313,10 @@ newdirent( > int error; > > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > - error = libxfs_dir2_createname(tp, pip, name, namelen, > + error = libxfs_dir2_createname(tp, pip, (uchar_t*)name, namelen, > inum, first, flist, total); > else > - error = libxfs_dir_createname(tp, pip, name, namelen, > + error = libxfs_dir_createname(tp, pip, (uchar_t*)name, namelen, > inum, first, flist, total); > if (error) > fail(_("directory createname error"), error); > Index: xfsprogs/repair/phase6.c > =================================================================== > --- xfsprogs.orig/repair/phase6.c 2006-12-08 09:58:32.542065000 +1100 > +++ xfsprogs/repair/phase6.c 2006-12-08 10:02:24.364553000 +1100 > @@ -338,10 +338,12 @@ dir_createname(xfs_mount_t *mp, xfs_tran > xfs_bmap_free_t *flist, xfs_extlen_t total) > { > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > - return libxfs_dir2_createname(tp, pip, name, namelen, > + return libxfs_dir2_createname(tp, pip, > + (uchar_t *)name, namelen, > inum, first, flist, total); > else > - return libxfs_dir_createname(tp, pip, name, namelen, > + return libxfs_dir_createname(tp, pip, > + (uchar_t *)name, namelen, > inum, first, flist, total); > } > > @@ -350,9 +352,11 @@ dir_lookup(xfs_mount_t *mp, xfs_trans_t > int namelen, xfs_ino_t *inum) > { > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > - return libxfs_dir2_lookup(tp, dp, name, namelen, inum); > + return libxfs_dir2_lookup(tp, dp, > + (uchar_t *)name, namelen, inum); > else > - return libxfs_dir_lookup(tp, dp, name, namelen, inum); > + return libxfs_dir_lookup(tp, dp, > + (uchar_t *)name, namelen, inum); > } > > static int > @@ -361,23 +365,12 @@ dir_replace(xfs_mount_t *mp, xfs_trans_t > xfs_bmap_free_t *flist, xfs_extlen_t total) > { > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > - return libxfs_dir2_replace(tp, dp, name, namelen, inum, > + return libxfs_dir2_replace(tp, dp, > + (uchar_t *)name, namelen, inum, > firstblock, flist, total); > else > - return libxfs_dir_replace(tp, dp, name, namelen, inum, > - firstblock, flist, total); > -} > - > -static int > -dir_removename(xfs_mount_t *mp, xfs_trans_t *tp, xfs_inode_t *dp, char *name, > - int namelen, xfs_ino_t inum, xfs_fsblock_t *firstblock, > - xfs_bmap_free_t *flist, xfs_extlen_t total) > -{ > - if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > - return libxfs_dir2_removename(tp, dp, name, namelen, inum, > - firstblock, flist, total); > - else > - return libxfs_dir_removename(tp, dp, name, namelen, inum, > + return libxfs_dir_replace(tp, dp, > + (uchar_t *)name, namelen, inum, > firstblock, flist, total); > } > > @@ -387,10 +380,12 @@ dir_bogus_removename(xfs_mount_t *mp, xf > xfs_extlen_t total, xfs_dahash_t hashval, int namelen) > { > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > - return libxfs_dir2_bogus_removename(tp, dp, name, firstblock, > + return libxfs_dir2_bogus_removename(tp, dp, > + (uchar_t *)name, firstblock, > flist, total, hashval, namelen); > else > - return libxfs_dir_bogus_removename(tp, dp, name, firstblock, > + return libxfs_dir_bogus_removename(tp, dp, > + (uchar_t *)name, firstblock, > flist, total, hashval, namelen); > } > > @@ -1863,7 +1858,7 @@ longform_dir2_rebuild( > libxfs_trans_ihold(tp, ip); > > XFS_BMAP_INIT(&flist, &firstblock); > - if ((error = libxfs_dir2_createname(tp, ip, (char*)p->name, > + if ((error = libxfs_dir2_createname(tp, ip, (uchar_t *)p->name, > p->namelen, p->inum, &firstblock, &flist, > nres))) { > do_warn( From owner-xfs@oss.sgi.com Fri Dec 8 12:25:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 08 Dec 2006 12:25:35 -0800 (PST) Received: from mail.lichtvoll.de (12.unused.teamix.net [194.150.191.12] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kB8KPQqw028987 for ; Fri, 8 Dec 2006 12:25:27 -0800 Received: from localhost (dslb-084-056-065-242.pools.arcor-ip.net [84.56.65.242]) by mail.lichtvoll.de (Postfix) with ESMTP id 418945AD2D for ; Fri, 8 Dec 2006 21:00:04 +0100 (CET) From: Martin Steigerwald To: linux-xfs@oss.sgi.com Subject: invalid directory entry - bad magic number on inode Date: Fri, 8 Dec 2006 20:59:59 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200612082100.00395.Martin@lichtvoll.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id kB8KPSqw028991 X-archive-position: 9944 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 7017 Lines: 194 Hello, today, I got a strange problem with XFS that seemed to affect only one file. I stumbled upon it as I tried to remove the package serendipity on my Debian mostly Etch/some Sid/probably some Experimental: ----------------------------------------------------------------------- deepdance:~#130> aptitude purge serendipity Paketlisten werden gelesen... Fertig [...] Entferne serendipity ... dpkg: Fehler beim Bearbeiten von serendipity (--purge): Kann »/usr/share/serendipity/www/plugins/serendipity_event_livesearch/lang_pt_PT.inc.php« nicht entfernen: Das Argument ist ungültig Fehler traten auf beim Bearbeiten von: serendipity [...] ----------------------------------------------------------------------- That means that the package could not removed cause that PHP file could not be removed "Das Argument ist ungültig" means in english => "The argument is invalid" ----------------------------------------------------------------------- deepdance:~#2> ls -l /usr/share/serendipity/www/plugins/serendipity_event_livesearch/lang_pt_PT.inc.php ls: /usr/share/serendipity/www/plugins/serendipity_event_livesearch/lang_pt_PT.inc.php: Das Argument ist ungültig deepdance:~#2> ls -l /usr/share/serendipity/www/plugins/serendipity_event_livesearch/ insgesamt 0 ?--------- ? ? ? ? ? /usr/share/serendipity/www/plugins/serendipity_event_livesearch/lang_pt_PT.inc.php ----------------------------------------------------------------------- Now that looks strange. I thought I better boot into SUSE 10.1 and check my Debian root partition. ----------------------------------------------------------------------- deepdance:~ # xfs_check /dev/hda5 agi unlinked bucket 14 is 4110 in ag 0 (inode=4110) agi unlinked bucket 25 is 12633 in ag 0 (inode=12633) agi unlinked bucket 33 is 929 in ag 0 (inode=929) [... more of that kinda usual stuff ...] agi unlinked bucket 60 is 233532 in ag 9 (inode=37982268) agi unlinked bucket 61 is 233533 in ag 9 (inode=37982269) bad magic number 0 for inode 43113648 agi unlinked bucket 0 is 74624 in ag 11 (inode=46211968) agi unlinked bucket 1 is 74625 in ag 11 (inode=46211969) [...] agi unlinked bucket 57 is 47865 in ag 15 (inode=62962425) agi unlinked bucket 58 is 164986 in ag 15 (inode=63079546) block 10/73160 type unknown not expected allocated inode 4110 has 0 link count allocated inode 929 has 0 link count [... more of that ...] allocated inode 37982268 has 0 link count allocated inode 37982269 has 0 link count link count mismatch for inode 43113648 (name ?), nlink 0, counted 1 allocated inode 46140958 has 0 link count allocated inode 46137510 has 0 link count [... more of that ...] ----------------------------------------------------------------------- Hmmm, seems 43113648 is corrupted. As I need the laptop tomorrow for work I ran xfs_repair without much further diagnostics. It seems to have fixed it the problem properly: ----------------------------------------------------------------------- deepdance:~ # xfs_repair /dev/hda5 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... error following ag 1 unlinked list error following ag 2 unlinked list error following ag 3 unlinked list error following ag 8 unlinked list error following ag 11 unlinked list error following ag 12 unlinked list error following ag 15 unlinked list ----------------------------------------------------------------------- Are those above harmless? ----------------------------------------------------------------------- Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 bad magic number 0x0 on inode 43113648 bad version number 0x2d on inode 43113648 bad inode format in inode 43113648 bad magic number 0x0 on inode 43113648, resetting magic number bad version number 0x2d on inode 43113648, resetting version number bad inode format in inode 43113648 cleared inode 43113648 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - marking entry "lost+found" to be deleted - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 entry "lang_pt_PT.inc.php" in shortform directory 43058698 references free inode 43113648 junking entry "lang_pt_PT.inc.php" in directory inode 43058698 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... rebuilding directory inode 128 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 929, moving to lost+found disconnected inode 3366, moving to lost+found [...more of those...] ----------------------------------------------------------------------- Another run of xfs_check remains completely silent. All seems well again. Anyone any idea what that might have been? Unfortunately I cannot provide much further info. I do not even now when this problem might have occured first. There are no traces of XFS problems in /var/log/syslog. I will do a backup now and then run a SMART offline check just to be sure... Any hints on what I could try if it ever happens again? Suppose I can save out the bad inode contents before I let xfs_repair fix it... Aside that so far no problems with XFS since 2.6.17.7 whatsoever ;-). This is on IBM ThinkPad T23 with 768 MB (it swapped out nevertheless... I had two KDE sessions running and whatnot...) and this kernel: deepdance:~> cat /proc/version Linux version 2.6.18.1-ck1-tp23-sws2-2.2.8 (root@deepdance) (gcc-Version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #1 PREEMPT Wed Oct 25 11:55:21 CEST 2006 It contains suspend2 patches by Nigel Cunningham and responsive ness patches by Con Koliva. Apart from that it is vanilla. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sun Dec 10 01:05:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 10 Dec 2006 01:06:04 -0800 (PST) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBA95sqw031700 for ; Sun, 10 Dec 2006 01:05:56 -0800 Received: (qmail 63650 invoked from network); 10 Dec 2006 09:05:04 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@24.5.75.45 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 10 Dec 2006 09:05:04 -0000 X-YMail-OSG: ozTXK1MVM1mV_8QWe5dYSOvKCO0XznaQ0_4UdJ5Rf46YiXwkhbEPOt6IGqpEg06_LXHdw7F0JduKM9xoEJ1ZW1zLLLhSIbov._gkPLMT7mioLVqui.51aDI6FX1LJTCZGnNtR2fw0sqNFw-- Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 2B6EB182421B; Sun, 10 Dec 2006 01:04:55 -0800 (PST) Date: Sun, 10 Dec 2006 01:04:55 -0800 From: Chris Wedgwood To: Eric Sandeen Cc: Dennis Varouxis , xfs@oss.sgi.com Subject: Re: Unable to mount XFS partition on Sun Ultra/Linux 2.6.17 - Function not implemented Message-ID: <20061210090454.GB6192@tuatara.stupidest.org> References: <457997E6.60900@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457997E6.60900@sandeen.net> X-archive-position: 9949 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs Content-Length: 191 Lines: 6 On Fri, Dec 08, 2006 at 10:50:46AM -0600, Eric Sandeen wrote: > Looks like version one directories, recently ripped out of Linux... there should be a prinkt to this effect for these cases From owner-xfs@oss.sgi.com Sun Dec 10 07:49:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 10 Dec 2006 07:49:21 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.233]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBAFnDqw007391 for ; Sun, 10 Dec 2006 07:49:14 -0800 Received: by wx-out-0506.google.com with SMTP id t4so1210542wxc for ; Sun, 10 Dec 2006 07:48:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=McQz15B42soL3ix/MoQRNHVeZS6I1zZeJkwhCDRnGaEbWV5MSabFRx5gqF1nhf33Pugy/kGn9zQBHmxmCxVi6Ra+KooCciKUNpKAYRvFS2RltxD5WqK6nxGDEtcVu9PxEVA7KA2tQarZeyjR1UXwwXZToITQHwbPF+eKe8WN4yM= Received: by 10.90.105.20 with SMTP id d20mr6019211agc.1165765703027; Sun, 10 Dec 2006 07:48:23 -0800 (PST) Received: by 10.90.29.7 with HTTP; Sun, 10 Dec 2006 07:48:22 -0800 (PST) Message-ID: <9a8748490612100748w5caa69c5we3e35c2d18a836e2@mail.gmail.com> Date: Sun, 10 Dec 2006 16:48:23 +0100 From: "Jesper Juhl" To: "David Chinner" Subject: Re: XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c (kernel 2.6.18.1) Cc: "Linux Kernel Mailing List" , xfs@oss.sgi.com, xfs-masters@oss.sgi.com, "Keith Owens" In-Reply-To: <9a8748490611292151m57cdbf4kacebb4dd20b95147@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9a8748490611280749k5c97d21bx2e499d2209d27dfe@mail.gmail.com> <20061129013214.GH44411608@melbourne.sgi.com> <9a8748490611290117oc0ba880v1a6407bc4f41088f@mail.gmail.com> <20061130020734.GB37654165@melbourne.sgi.com> <9a8748490611292151m57cdbf4kacebb4dd20b95147@mail.gmail.com> X-archive-position: 9950 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jesper.juhl@gmail.com Precedence: bulk X-list: xfs Content-Length: 6095 Lines: 130 On 30/11/06, Jesper Juhl wrote: > On 30/11/06, David Chinner wrote: > > On Wed, Nov 29, 2006 at 10:17:25AM +0100, Jesper Juhl wrote: > > > On 29/11/06, David Chinner wrote: > > > >On Tue, Nov 28, 2006 at 04:49:00PM +0100, Jesper Juhl wrote: > > > >> Filesystem "dm-1": XFS internal error xfs_trans_cancel at line 1138 of > > > >> file fs/xfs/xfs_trans.c. Caller 0xffffffff8034b47e > > > >> For your information; I just got this again with a different filesystem (see below). > > > >> Call Trace: > > > >> [] show_trace+0xb2/0x380 > > > >> [] dump_stack+0x15/0x20 > > > >> [] xfs_error_report+0x3c/0x50 > > > >> [] xfs_trans_cancel+0x6e/0x130 > > > >> [] xfs_create+0x5ee/0x6a0 > > > >> [] xfs_vn_mknod+0x156/0x2e0 > > > >> [] xfs_vn_create+0xb/0x10 > > > >> [] vfs_create+0x8c/0xd0 > > > >> [] nfsd_create_v3+0x31a/0x560 > > > >> [] nfsd3_proc_create+0x148/0x170 > > > >> [] nfsd_dispatch+0xf9/0x1e0 > > > >> [] svc_process+0x437/0x6e0 > > > >> [] nfsd+0x1cd/0x360 > > > >> [] child_rip+0xa/0x12 > > > >> xfs_force_shutdown(dm-1,0x8) called from line 1139 of file > > > >> fs/xfs/xfs_trans.c. Return address = 0xffffffff80359daa > > > > > > > >We shut down the filesystem because we cancelled a dirty transaction. > > > >Once we start to dirty the incore objects, we can't roll back to > > > >an unchanged state if a subsequent fatal error occurs during the > > > >transaction and we have to abort it. > > > > > > > So you are saying that there's nothing I can do to prevent this from > > > happening in the future? > > > > Pretty much - we need to work out what is going wrong and > > we can't from teh shutdown message above - the error has > > occurred in a path that doesn't have error report traps > > in it. > > > > Is this reproducable? > > > Not on demand, no. It has happened only this once as far as I know and > for unknown reasons. > This time it *is* reproducible, so if you want me to try something let me know fast since I have to delete the fs as soon as I have copied all the data to a new one. > > > >If I understand historic occurrences of this correctly, there is > > > >a possibility that it can be triggered in ENOMEM situations. Was your > > > >machine running out of memoy when this occurred? > > > > > > > Not really. I just checked my monitoring software and, at the time > > > this happened, the box had ~5.9G RAM free (of 8G total) and no swap > > > used (but 11G available). > > > > Ok. Sounds like we need more error reporting points inserted > > into that code so we dump an error earlier and hence have some > > hope of working out what went wrong next time..... > > > > OOC, there weren't any I/O errors reported before this shutdown? > > > No. I looked but found none. > This time the server was running 2.6.19 : Dec 10 15:09:21 nfsserver2 kernel: Filesystem "dm-6": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0xffffffff8034263c Dec 10 15:09:21 nfsserver2 kernel: Dec 10 15:09:21 nfsserver2 kernel: Call Trace: Dec 10 15:09:21 nfsserver2 kernel: [] dump_trace+0xb3/0x42e Dec 10 15:09:21 nfsserver2 kernel: [] show_trace+0x3c/0x55 Dec 10 15:09:21 nfsserver2 kernel: [] dump_stack+0x15/0x17 Dec 10 15:09:21 nfsserver2 kernel: [] xfs_error_report+0x3c/0x3e Dec 10 15:09:21 nfsserver2 kernel: [] xfs_trans_cancel+0x65/0x109 Dec 10 15:09:21 nfsserver2 kernel: [] xfs_create+0x5bb/0x613 Dec 10 15:09:21 nfsserver2 kernel: [] xfs_vn_mknod+0x141/0x2b6 Dec 10 15:09:21 nfsserver2 kernel: [] xfs_vn_create+0xb/0xd Dec 10 15:09:21 nfsserver2 kernel: [] vfs_create+0x7a/0xb1 Dec 10 15:09:21 nfsserver2 kernel: [] nfsd_create_v3+0x300/0x548 Dec 10 15:09:21 nfsserver2 kernel: [] nfsd3_proc_create+0x152/0x164 Dec 10 15:09:21 nfsserver2 kernel: [] nfsd_dispatch+0xea/0x1bd Dec 10 15:09:21 nfsserver2 kernel: [] svc_process+0x3ee/0x6fb Dec 10 15:09:21 nfsserver2 kernel: [] nfsd+0x198/0x2bd Dec 10 15:09:21 nfsserver2 kernel: [] child_rip+0xa/0x12 Dec 10 15:09:21 nfsserver2 kernel: Dec 10 15:09:21 nfsserver2 kernel: xfs_force_shutdown(dm-6,0x8) called from line 1139 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff8034e9ed Dec 10 15:09:21 nfsserver2 kernel: Filesystem "dm-6": Corruption of in-memory data detected. Shutting down filesystem: dm-6 Dec 10 15:09:21 nfsserver2 kernel: Please umount the filesystem, and rectify the problem(s) Dec 10 15:12:23 nfsserver2 kernel: nfsd: last server has exited Dec 10 15:12:23 nfsserver2 kernel: nfsd: unexporting all filesystems Dec 10 15:12:26 nfsserver2 kernel: xfs_force_shutdown(dm-6,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return addres s = 0xffffffff8034e9ed If I unmount and then remount the filesystem the log gets replayed OK, I can then unmount it and run xfs_repair on it and it finds no problems, *but* when I then mount it again and the webserver that uses the filesystem access it via NFS it explodes again - every single time, it's quite reproducible. I'm currently in the process of copying all the data to a new XFS filesystem in the hope that the new filesystem will be OK - the copy seems to be proceeding fine. Unfortunately I can't keep the current filesystem around for diagnostics work since it's a production server and I don't have space available to let the old and new copy co-exist, so I have to delete the current one as soon as I have copied all the data off. -- Jesper Juhl Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html From owner-xfs@oss.sgi.com Sun Dec 10 08:47:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 10 Dec 2006 08:47:42 -0800 (PST) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBAGlZqw017349 for ; Sun, 10 Dec 2006 08:47:36 -0800 Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id AEC50B93FAC for ; Sun, 10 Dec 2006 17:21:06 +0100 (CET) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25138-07 for ; Sun, 10 Dec 2006 17:21:04 +0100 (CET) Received: from robotnik.home.krienke.org (C6c87.c.strato-dslnet.de [62.104.108.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id 916BAB92110 for ; Sun, 10 Dec 2006 17:21:04 +0100 (CET) From: Rainer Krienke To: linux-xfs@oss.sgi.com Subject: Hints to create the optimal xfs filesystem Date: Sun, 10 Dec 2006 17:20:53 +0100 User-Agent: KMail/1.9.5 Organization: Uni Koblenz MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2252995.ph6jNzc5xy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612101720.58144.krienke@uni-koblenz.de> X-archive-position: 9951 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: krienke@uni-koblenz.de Precedence: bulk X-list: xfs Content-Length: 1940 Lines: 57 --nextPart2252995.ph6jNzc5xy Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I am running a fileserver with SuSE SLES10 on it that has a 5TB RAID6 devic= e=20 attached to it. The RAID has 1GB cache memory (battery backed up). Ob this= =20 raid device I use EVMS to manage the space available. There will be several= =20 evms volumes with xfs on them on this raid and I ask myself if there are an= y=20 hints how to create the optimal filesystem with high read and write=20 performace. Or is it sufficient to stay with the defaults mkfs.xfs provides? The filesystem have a size that range from 50GB to 500GB and mostly contain= =20 user home directories, i.e. they will probably contain a lot of small files. One point I think about is if it would make sense to create the xfs=20 filesystems using an external logging device. Does anyone have experience i= n=20 this? How big should the log be compared to the filesystem? Is it possible = to=20 change the loggining mode of an existing XFS filesystem from internal to an= =20 external device without recreating (destroying) it? Can anyone comment on this? Thanks Rainer Krienke --=20 --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022 Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html --------------------------------------------------------------------------- --nextPart2252995.ph6jNzc5xy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBFfDPqaldtjc/KDEoRAslIAKDJN87goaBT259ZYz9VIydJc90/tgCfctOW n/JdxpiTxe8h5mH2qghpLQ4= =ZM4d -----END PGP SIGNATURE----- --nextPart2252995.ph6jNzc5xy-- From owner-xfs@oss.sgi.com Sun Dec 10 14:39:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 10 Dec 2006 14:39:26 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBAMdFqw022802 for ; Sun, 10 Dec 2006 14:39:18 -0800 Received: from [192.168.5.88] (unknown [124.178.235.100]) by postoffice.aconex.com (Postfix) with ESMTP id F0189AAC26D; Mon, 11 Dec 2006 09:33:08 +1100 (EST) Subject: Re: REOPEN 958693 - Restore xfs/list.h From: Nathan Scott Reply-To: nscott@aconex.com To: David Chatterton , bnaujok@sgi.com Cc: xfs@oss.sgi.com In-Reply-To: <20061208053305.5136658CA5AD@chook.melbourne.sgi.com> References: <20061208053305.5136658CA5AD@chook.melbourne.sgi.com> Content-Type: text/plain Organization: Aconex Date: Mon, 11 Dec 2006 19:36:36 +1100 Message-Id: <1165826196.5572.7.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 9952 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 266 Lines: 11 On Fri, 2006-12-08 at 16:33 +1100, David Chatterton wrote: > Undo rename of xfs/list.h since this is effectively part of the > XFS development interface that has already shipped. Thanks! I'll get updated Debian packages uploaded later today. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Dec 10 15:32:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 10 Dec 2006 15:32:10 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBANVvqw027694 for ; Sun, 10 Dec 2006 15:31:59 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13962; Mon, 11 Dec 2006 10:30:58 +1100 Message-Id: <200612102330.KAA13962@larry.melbourne.sgi.com> From: "Barry Naujok" To: Cc: Subject: RE: [PATCH] fix compiler warnings Date: Mon, 11 Dec 2006 10:37:00 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acca6TFKgMVYn3g+QluYJPuetfplcwBypowQ In-Reply-To: <457997C6.4010307@sgi.com> X-archive-position: 9953 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 51128 Lines: 1272 Hmmm... the TAKE message vanished into thin air. Here's the contents: Fix "pointer targets in assignment differ in signedness" warnings Date: Fri Dec 8 15:41:56 AEDT 2006 Workarea: snort.melbourne.sgi.com:/home/bnaujok/isms/repair Inspected by: nathans@debian.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:27667a xfsprogs/db/hash.c - 1.8 - changed xfsprogs/db/check.c - 1.32 - changed xfsprogs/mkfs/proto.c - 1.19 - changed xfsprogs/libdisk/fstype.c - 1.11 - changed xfsprogs/libdisk/fstype.h - 1.10 - changed xfsprogs/include/libxfs.h - 1.58 - changed xfsprogs/repair/phase6.c - 1.35 - changed xfsprogs/libxfs/xfs_dir2_block.c - 1.15 - changed xfsprogs/libxfs/xfs_dir.c - 1.20 - changed xfsprogs/libxfs/xfs_dir_leaf.c - 1.19 - changed xfsprogs/libxfs/xfs_attr_leaf.c - 1.18 - changed xfsprogs/libxfs/util.c - 1.20 - changed xfsprogs/libxfs/xfs_dir2.c - 1.17 - changed xfsprogs/libxfs/xfs_attr.c - 1.5 - changed - Fix "pointer targets in assignment differ in signedness" warnings > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Lachlan McIlroy > Sent: Saturday, 9 December 2006 3:50 AM > To: nscott@aconex.com > Cc: bnaujok@sgi.com; chatz@sgi.com; xfs@oss.sgi.com > Subject: Re: [PATCH] fix compiler warnings > > Barry, I see you've already checked this in (good thing I checked > before reviewing the changes). Did you send a TAKE for this? > > Nathan Scott wrote: > > The xfsprogs userspace builds have been generating hundreds of > > warnings with recent gcc versions for some time, due to the > > char signedness inconsistencies we have in places. Here's a > > patch to clean that up, so we can at least see the interesting > > warnings cropping up now. > > > > cheers. > > > > > > > > > -------------------------------------------------------------- > ---------- > > > > util.c: In function 'libxfs_dir_bogus_removename': > > util.c:470: warning: pointer targets in assignment differ > in signedness > > util.c: In function 'libxfs_dir2_bogus_removename': > > util.c:531: warning: pointer targets in assignment differ > in signedness > > > > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" > -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir.c > -fPIC -DPIC -o .libs/xfs_dir.o > > xfs_dir.c: In function 'xfs_dir_startup': > > xfs_dir.c:36: warning: pointer targets in passing argument > 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir.c:37: warning: pointer targets in passing argument > 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir.c: In function 'libxfs_dir_createname': > > xfs_dir.c:118: warning: pointer targets in assignment > differ in signedness > > xfs_dir.c:120: warning: pointer targets in passing argument > 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir.c: In function 'libxfs_dir_removename': > > xfs_dir.c:180: warning: pointer targets in assignment > differ in signedness > > xfs_dir.c:182: warning: pointer targets in passing argument > 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir.c: In function 'libxfs_dir_lookup': > > xfs_dir.c:224: warning: pointer targets in assignment > differ in signedness > > xfs_dir.c:226: warning: pointer targets in passing argument > 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir.c: In function 'libxfs_dir_replace': > > xfs_dir.c:269: warning: pointer targets in assignment > differ in signedness > > xfs_dir.c:271: warning: pointer targets in passing argument > 1 of 'libxfs_da_hashname' differ in signedness > > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" > -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir_leaf.c > -fPIC -DPIC -o .libs/xfs_dir_leaf.o > > xfs_dir_leaf.c: In function 'libxfs_dir_shortform_to_leaf': > > xfs_dir_leaf.c:290: warning: pointer targets in assignment > differ in signedness > > xfs_dir_leaf.c:306: warning: pointer targets in assignment > differ in signedness > > xfs_dir_leaf.c:316: warning: pointer targets in assignment > differ in signedness > > xfs_dir_leaf.c:319: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir_leaf.c: In function 'xfs_dir_leaf_to_shortform': > > xfs_dir_leaf.c:452: warning: pointer targets in assignment > differ in signedness > > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" > -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -funsigned-char -fno-strict-aliasing -Wall -c xfs_dir2.c > -fPIC -DPIC -o .libs/xfs_dir2.o > > xfs_dir2.c: In function 'libxfs_dir2_createname': > > xfs_dir2.c:99: warning: pointer targets in assignment > differ in signedness > > xfs_dir2.c:101: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2.c: In function 'libxfs_dir2_lookup': > > xfs_dir2.c:150: warning: pointer targets in assignment > differ in signedness > > xfs_dir2.c:152: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2.c: In function 'libxfs_dir2_removename': > > xfs_dir2.c:207: warning: pointer targets in assignment > differ in signedness > > xfs_dir2.c:209: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2.c: In function 'libxfs_dir2_replace': > > xfs_dir2.c:262: warning: pointer targets in assignment > differ in signedness > > xfs_dir2.c:264: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" > -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -funsigned-char -fno-strict-aliasing -Wall -c xfs_attr_leaf.c > -fPIC -DPIC -o .libs/xfs_attr_leaf.o > > xfs_attr_leaf.c: In function 'xfs_attr_shortform_to_leaf': > > xfs_attr_leaf.c:375: warning: pointer targets in assignment > differ in signedness > > xfs_attr_leaf.c:377: warning: pointer targets in assignment > differ in signedness > > xfs_attr_leaf.c:380: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_attr_leaf.c: In function 'xfs_attr_leaf_to_shortform': > > xfs_attr_leaf.c:513: warning: pointer targets in assignment > differ in signedness > > xfs_attr_leaf.c:515: warning: pointer targets in assignment > differ in signedness > > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" > -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -funsigned-char -fno-strict-aliasing -Wall -c > xfs_dir2_block.c -fPIC -DPIC -o .libs/xfs_dir2_block.o > > xfs_dir2_block.c: In function 'libxfs_dir2_sf_to_block': > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > xfs_dir2_block.c:1049: warning: pointer targets in passing > argument 1 of 'libxfs_da_hashname' differ in signedness > > gcc -I. -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" > -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -funsigned-char -fno-strict-aliasing -Wall -c xfs_attr.c > -fPIC -DPIC -o .libs/xfs_attr.o > > xfs_attr.c: In function 'libxfs_attr_set_int': > > xfs_attr.c:106: warning: pointer targets in assignment > differ in signedness > > xfs_attr.c:108: warning: pointer targets in assignment > differ in signedness > > xfs_attr.c: In function 'libxfs_attr_remove_int': > > xfs_attr.c:316: warning: pointer targets in assignment > differ in signedness > > xfs_attr.c: In function 'xfs_attr_rmtval_set': > > xfs_attr.c:1292: warning: pointer targets in assignment > differ in signedness > > gcc -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" > -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -funsigned-char -fno-strict-aliasing -Wall -c fstype.c -fPIC > -DPIC -o .libs/fstype.o > > fstype.c: In function 'is_reiserfs_magic_string': > > fstype.c:158: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:158: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:158: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:158: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:158: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:158: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:158: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:158: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:160: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:160: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:160: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:160: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:160: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:160: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:160: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:160: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c: In function 'fstype': > > fstype.c:222: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:222: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:222: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:222: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:222: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:222: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:222: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:222: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:228: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:228: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:228: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:228: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:228: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:228: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:228: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:228: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:234: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:234: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:234: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:234: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:234: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:234: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:234: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:234: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:235: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:235: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:235: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:235: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:235: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:235: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:235: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:235: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:236: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:236: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:236: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:236: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:236: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:236: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:236: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:236: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:237: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:237: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:237: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:237: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:237: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:237: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:237: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:237: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:238: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:238: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:238: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:238: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:238: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:238: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:238: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:238: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:241: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:241: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:241: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:241: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:241: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:241: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:241: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:241: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:242: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:242: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:242: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:242: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:242: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:242: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:242: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:242: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:243: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:243: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:243: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:243: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:243: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:243: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:243: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:243: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > fstype.c:244: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:244: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:244: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:244: warning: pointer targets in passing argument > 1 of 'strlen' differ in signedness > > fstype.c:244: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:244: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:244: warning: pointer targets in passing argument > 1 of '__builtin_strcmp' differ in signedness > > fstype.c:244: warning: pointer targets in passing argument > 1 of 'strncmp' differ in signedness > > > > gcc -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" > -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -funsigned-char -fno-strict-aliasing -Wall -DENABLE_READLINE > -c -o check.o check.c > > check.c: In function 'process_data_dir_v2': > > check.c:2302: warning: pointer targets in passing argument > 1 of 'libxfs_da_hashname' differ in signedness > > > > gcc -g -O2 -DNDEBUG -DVERSION=\"2.8.18\" > -DLOCALEDIR=\"/usr/share/locale\" -DPACKAGE=\"xfsprogs\" > -I../include -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 > -funsigned-char -fno-strict-aliasing -Wall -DENABLE_READLINE > -c -o hash.o hash.c > > hash.c: In function 'hash_f': > > hash.c:55: warning: pointer targets in passing argument 1 > of 'libxfs_da_hashname' differ in signedness > > > > phase6.c: In function 'dir_bogus_removename': > > phase6.c:391: warning: pointer targets in passing argument > 3 of 'libxfs_dir2_bogus_removename' differ in signedness > > phase6.c:394: warning: pointer targets in passing argument > 3 of 'libxfs_dir_bogus_removename' differ in signedness > > phase6.c: At top level: > > phase6.c:375: warning: 'dir_removename' defined but not used > > Index: xfsprogs/libxfs/util.c > > =================================================================== > > --- xfsprogs.orig/libxfs/util.c 2006-12-08 > 09:25:43.471005750 +1100 > > +++ xfsprogs/libxfs/util.c 2006-12-08 09:26:31.165986500 +1100 > > @@ -452,7 +452,7 @@ libxfs_bmap_next_offset( > > * This was originally in the kernel, but only used in xfs_repair. > > */ > > int > > -xfs_dir_bogus_removename(xfs_trans_t *trans, xfs_inode_t > *dp, char *name, > > +xfs_dir_bogus_removename(xfs_trans_t *trans, xfs_inode_t > *dp, uchar_t *name, > > xfs_fsblock_t *firstblock, xfs_bmap_free_t *flist, > > xfs_extlen_t total, xfs_dahash_t hashval, int namelen) > > { > > @@ -510,7 +510,7 @@ int > > xfs_dir2_bogus_removename( > > xfs_trans_t *tp, /* transaction pointer */ > > xfs_inode_t *dp, /* incore directory inode */ > > - char *name, /* name of entry to remove */ > > + uchar_t *name, /* name of entry to remove */ > > xfs_fsblock_t *first, /* bmap's firstblock */ > > xfs_bmap_free_t *flist, /* bmap's freeblock list */ > > xfs_extlen_t total, /* bmap's total block count */ > > Index: xfsprogs/include/libxfs.h > > =================================================================== > > --- xfsprogs.orig/include/libxfs.h 2006-12-08 > 09:25:43.547010500 +1100 > > +++ xfsprogs/include/libxfs.h 2006-12-08 > 09:26:31.165986500 +1100 > > @@ -429,33 +429,33 @@ extern void libxfs_dir_mount (xfs_mount_ > > extern void libxfs_dir2_mount (xfs_mount_t *); > > extern int libxfs_dir_init (xfs_trans_t *, xfs_inode_t *, > xfs_inode_t *); > > extern int libxfs_dir2_init (xfs_trans_t *, xfs_inode_t *, > xfs_inode_t *); > > -extern int libxfs_dir_createname (xfs_trans_t *, > xfs_inode_t *, char *, > > +extern int libxfs_dir_createname (xfs_trans_t *, > xfs_inode_t *, uchar_t *, > > int, xfs_ino_t, xfs_fsblock_t *, > > xfs_bmap_free_t *, xfs_extlen_t); > > -extern int libxfs_dir2_createname (xfs_trans_t *, > xfs_inode_t *, char *, > > +extern int libxfs_dir2_createname (xfs_trans_t *, > xfs_inode_t *, uchar_t *, > > int, xfs_ino_t, xfs_fsblock_t *, > > xfs_bmap_free_t *, xfs_extlen_t); > > extern int libxfs_dir_lookup (xfs_trans_t *, xfs_inode_t *, > > - char *, int, xfs_ino_t *); > > + uchar_t *, int, xfs_ino_t *); > > extern int libxfs_dir2_lookup (xfs_trans_t *, xfs_inode_t *, > > - char *, int, xfs_ino_t *); > > + uchar_t *, int, xfs_ino_t *); > > extern int libxfs_dir_replace (xfs_trans_t *, xfs_inode_t *, > > - char *, int, xfs_ino_t, xfs_fsblock_t *, > > + uchar_t *, int, xfs_ino_t, > xfs_fsblock_t *, > > xfs_bmap_free_t *, xfs_extlen_t); > > extern int libxfs_dir2_replace (xfs_trans_t *, xfs_inode_t *, > > - char *, int, xfs_ino_t, xfs_fsblock_t *, > > + uchar_t *, int, xfs_ino_t, > xfs_fsblock_t *, > > xfs_bmap_free_t *, xfs_extlen_t); > > extern int libxfs_dir_removename (xfs_trans_t *, xfs_inode_t *, > > - char *, int, xfs_ino_t, xfs_fsblock_t *, > > + uchar_t *, int, xfs_ino_t, > xfs_fsblock_t *, > > xfs_bmap_free_t *, xfs_extlen_t); > > extern int libxfs_dir2_removename (xfs_trans_t *, xfs_inode_t *, > > - char *, int, xfs_ino_t, xfs_fsblock_t *, > > + uchar_t *, int, xfs_ino_t, > xfs_fsblock_t *, > > xfs_bmap_free_t *, xfs_extlen_t); > > extern int libxfs_dir_bogus_removename (xfs_trans_t *, > xfs_inode_t *, > > - char *, xfs_fsblock_t *, > xfs_bmap_free_t *, > > + uchar_t *, xfs_fsblock_t *, > xfs_bmap_free_t *, > > xfs_extlen_t, xfs_dahash_t, int); > > extern int libxfs_dir2_bogus_removename (xfs_trans_t *, > xfs_inode_t *, > > - char *, xfs_fsblock_t *, > xfs_bmap_free_t *, > > + uchar_t *, xfs_fsblock_t *, > xfs_bmap_free_t *, > > xfs_extlen_t, xfs_dahash_t, int); > > > > > > Index: xfsprogs/libxfs/xfs_dir.c > > =================================================================== > > --- xfsprogs.orig/libxfs/xfs_dir.c 2006-12-08 > 09:25:43.479006250 +1100 > > +++ xfsprogs/libxfs/xfs_dir.c 2006-12-08 > 09:26:31.165986500 +1100 > > @@ -33,8 +33,8 @@ xfs_dahash_t xfs_dir_hash_dot, xfs_dir_h > > void > > xfs_dir_startup(void) > > { > > - xfs_dir_hash_dot = xfs_da_hashname(".", 1); > > - xfs_dir_hash_dotdot = xfs_da_hashname("..", 2); > > + xfs_dir_hash_dot = xfs_da_hashname((const uchar_t *) ".", 1); > > + xfs_dir_hash_dotdot = xfs_da_hashname((const uchar_t *) > "..", 2); > > } > > > > /* > > @@ -99,7 +99,7 @@ xfs_dir_init(xfs_trans_t *trans, xfs_ino > > * Transitions directory from shortform to Btree as necessary. > > */ > > STATIC int /* error */ > > -xfs_dir_createname(xfs_trans_t *trans, xfs_inode_t *dp, char *name, > > +xfs_dir_createname(xfs_trans_t *trans, xfs_inode_t *dp, > uchar_t *name, > > int namelen, xfs_ino_t inum, xfs_fsblock_t > *firstblock, > > xfs_bmap_free_t *flist, xfs_extlen_t total) > > { > > @@ -165,7 +165,7 @@ xfs_dir_createname(xfs_trans_t *trans, x > > * Transitions directory from Btree to shortform as necessary. > > */ > > STATIC int > /* error */ > > -xfs_dir_removename(xfs_trans_t *trans, xfs_inode_t *dp, char *name, > > +xfs_dir_removename(xfs_trans_t *trans, xfs_inode_t *dp, > uchar_t *name, > > int namelen, xfs_ino_t ino, xfs_fsblock_t > *firstblock, > > xfs_bmap_free_t *flist, xfs_extlen_t total) > > { > > @@ -209,7 +209,7 @@ xfs_dir_removename(xfs_trans_t *trans, x > > } > > > > STATIC int > /* error */ > > -xfs_dir_lookup(xfs_trans_t *trans, xfs_inode_t *dp, char > *name, int namelen, > > +xfs_dir_lookup(xfs_trans_t *trans, xfs_inode_t *dp, > uchar_t *name, int namelen, > > xfs_ino_t *inum) > > { > > xfs_da_args_t args; > > @@ -251,7 +251,7 @@ xfs_dir_lookup(xfs_trans_t *trans, xfs_i > > } > > > > STATIC int > /* error */ > > -xfs_dir_replace(xfs_trans_t *trans, xfs_inode_t *dp, char > *name, int namelen, > > +xfs_dir_replace(xfs_trans_t *trans, xfs_inode_t *dp, > uchar_t *name, int namelen, > > xfs_ino_t inum, > xfs_fsblock_t *firstblock, > > xfs_bmap_free_t *flist, > xfs_extlen_t total) > > { > > Index: xfsprogs/libxfs/xfs_dir2.c > > =================================================================== > > --- xfsprogs.orig/libxfs/xfs_dir2.c 2006-12-08 > 09:25:43.527009250 +1100 > > +++ xfsprogs/libxfs/xfs_dir2.c 2006-12-08 > 09:26:31.165986500 +1100 > > @@ -77,7 +77,7 @@ STATIC int > /* error */ > > xfs_dir2_createname( > > xfs_trans_t *tp, /* transaction > pointer */ > > xfs_inode_t *dp, /* incore > directory inode */ > > - char *name, /* new entry name */ > > + uchar_t *name, /* new entry name */ > > int namelen, /* new entry > name length */ > > xfs_ino_t inum, /* new entry > inode number */ > > xfs_fsblock_t *first, /* bmap's firstblock */ > > @@ -133,7 +133,7 @@ STATIC int > /* error */ > > xfs_dir2_lookup( > > xfs_trans_t *tp, /* transaction pointer */ > > xfs_inode_t *dp, /* incore directory inode */ > > - char *name, /* lookup name */ > > + uchar_t *name, /* lookup name */ > > int namelen, /* lookup name length */ > > xfs_ino_t *inum) /* out: inode number */ > > { > > @@ -188,7 +188,7 @@ STATIC int > /* error */ > > xfs_dir2_removename( > > xfs_trans_t *tp, /* transaction pointer */ > > xfs_inode_t *dp, /* incore directory inode */ > > - char *name, /* name of entry to remove */ > > + uchar_t *name, /* name of entry to remove */ > > int namelen, /* name length of entry > to remove */ > > xfs_ino_t ino, /* inode number of > entry to remove */ > > xfs_fsblock_t *first, /* bmap's firstblock */ > > @@ -240,7 +240,7 @@ STATIC int > /* error */ > > xfs_dir2_replace( > > xfs_trans_t *tp, /* transaction pointer */ > > xfs_inode_t *dp, /* incore directory inode */ > > - char *name, /* name of entry to replace */ > > + uchar_t *name, /* name of entry to replace */ > > int namelen, /* name length of entry > to replace */ > > xfs_ino_t inum, /* new inode number */ > > xfs_fsblock_t *first, /* bmap's firstblock */ > > Index: xfsprogs/libxfs/xfs_dir_leaf.c > > =================================================================== > > --- xfsprogs.orig/libxfs/xfs_dir_leaf.c 2006-12-08 > 09:25:43.503007750 +1100 > > +++ xfsprogs/libxfs/xfs_dir_leaf.c 2006-12-08 > 09:26:31.165986500 +1100 > > @@ -287,7 +287,7 @@ xfs_dir_shortform_to_leaf(xfs_da_args_t > > goto out; > > xfs_da_buf_done(bp); > > > > - args.name = "."; > > + args.name = (const uchar_t *) "."; > > args.namelen = 1; > > args.hashval = xfs_dir_hash_dot; > > args.inumber = dp->i_ino; > > @@ -303,7 +303,7 @@ xfs_dir_shortform_to_leaf(xfs_da_args_t > > if (retval) > > goto out; > > > > - args.name = ".."; > > + args.name = (const uchar_t *) ".."; > > args.namelen = 2; > > args.hashval = xfs_dir_hash_dotdot; > > args.inumber = inumber; > > @@ -313,9 +313,9 @@ xfs_dir_shortform_to_leaf(xfs_da_args_t > > > > sfe = &sf->list[0]; > > for (i = 0; i < INT_GET(sf->hdr.count, ARCH_CONVERT); i++) { > > - args.name = (char *)(sfe->name); > > + args.name = (const uchar_t *)(sfe->name); > > args.namelen = sfe->namelen; > > - args.hashval = xfs_da_hashname((char *)(sfe->name), > > + args.hashval = xfs_da_hashname((const uchar_t > *)(sfe->name), > > sfe->namelen); > > XFS_DIR_SF_GET_DIRINO(&sfe->inumber, &args.inumber); > > retval = xfs_dir_leaf_addname(&args); > > @@ -449,7 +449,7 @@ xfs_dir_leaf_to_shortform(xfs_da_args_t > > if (!entry->nameidx) > > continue; > > namest = XFS_DIR_LEAF_NAMESTRUCT(leaf, > INT_GET(entry->nameidx, ARCH_CONVERT)); > > - args.name = (char *)(namest->name); > > + args.name = (const uchar_t *)(namest->name); > > args.namelen = entry->namelen; > > args.hashval = INT_GET(entry->hashval, ARCH_CONVERT); > > XFS_DIR_SF_GET_DIRINO(&namest->inumber, &args.inumber); > > Index: xfsprogs/libxfs/xfs_attr_leaf.c > > =================================================================== > > --- xfsprogs.orig/libxfs/xfs_attr_leaf.c 2006-12-08 > 09:25:43.539010000 +1100 > > +++ xfsprogs/libxfs/xfs_attr_leaf.c 2006-12-08 > 09:26:31.169986750 +1100 > > @@ -372,11 +372,11 @@ xfs_attr_shortform_to_leaf(xfs_da_args_t > > > > sfe = &sf->list[0]; > > for (i = 0; i < INT_GET(sf->hdr.count, ARCH_CONVERT); i++) { > > - nargs.name = (char *)sfe->nameval; > > + nargs.name = (const uchar_t *)sfe->nameval; > > nargs.namelen = sfe->namelen; > > - nargs.value = (char *)&sfe->nameval[nargs.namelen]; > > + nargs.value = (uchar_t *)&sfe->nameval[nargs.namelen]; > > nargs.valuelen = INT_GET(sfe->valuelen, ARCH_CONVERT); > > - nargs.hashval = xfs_da_hashname((char *)sfe->nameval, > > + nargs.hashval = xfs_da_hashname((const uchar_t > *)sfe->nameval, > > sfe->namelen); > > nargs.flags = (sfe->flags & XFS_ATTR_SECURE) ? > ATTR_SECURE : > > ((sfe->flags & XFS_ATTR_ROOT) ? > ATTR_ROOT : 0); > > @@ -510,9 +510,9 @@ xfs_attr_leaf_to_shortform(xfs_dabuf_t * > > continue; > > ASSERT(entry->flags & XFS_ATTR_LOCAL); > > name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); > > - nargs.name = (char *)name_loc->nameval; > > + nargs.name = (const uchar_t *)name_loc->nameval; > > nargs.namelen = name_loc->namelen; > > - nargs.value = (char *)&name_loc->nameval[nargs.namelen]; > > + nargs.value = (uchar_t > *)&name_loc->nameval[nargs.namelen]; > > nargs.valuelen = INT_GET(name_loc->valuelen, > ARCH_CONVERT); > > nargs.hashval = INT_GET(entry->hashval, ARCH_CONVERT); > > nargs.flags = (entry->flags & XFS_ATTR_SECURE) > ? ATTR_SECURE : > > Index: xfsprogs/libxfs/xfs_attr.c > > =================================================================== > > --- xfsprogs.orig/libxfs/xfs_attr.c 2006-12-08 > 09:27:45.790650250 +1100 > > +++ xfsprogs/libxfs/xfs_attr.c 2006-12-08 > 09:30:15.307994500 +1100 > > @@ -103,9 +103,9 @@ xfs_attr_set_int(xfs_inode_t *dp, const > > * Fill in the arg structure for this request. > > */ > > memset((char *)&args, 0, sizeof(args)); > > - args.name = name; > > + args.name = (const uchar_t *)name; > > args.namelen = namelen; > > - args.value = value; > > + args.value = (uchar_t *)value; > > args.valuelen = valuelen; > > args.flags = flags; > > args.hashval = xfs_da_hashname(args.name, args.namelen); > > @@ -313,7 +313,7 @@ xfs_attr_remove_int(xfs_inode_t *dp, con > > * Fill in the arg structure for this request. > > */ > > memset((char *)&args, 0, sizeof(args)); > > - args.name = name; > > + args.name = (const uchar_t *)name; > > args.namelen = namelen; > > args.flags = flags; > > args.hashval = xfs_da_hashname(args.name, args.namelen); > > @@ -1289,7 +1289,7 @@ xfs_attr_rmtval_set(xfs_da_args_t *args) > > > > dp = args->dp; > > mp = dp->i_mount; > > - src = args->value; > > + src = (xfs_caddr_t)args->value; > > > > /* > > * Find a "hole" in the attribute address space large enough for > > Index: xfsprogs/libxfs/xfs_dir2_block.c > > =================================================================== > > --- xfsprogs.orig/libxfs/xfs_dir2_block.c 2006-12-08 > 09:26:53.483381250 +1100 > > +++ xfsprogs/libxfs/xfs_dir2_block.c 2006-12-08 > 09:27:10.736459500 +1100 > > @@ -1046,7 +1046,7 @@ xfs_dir2_sf_to_block( > > tagp = XFS_DIR2_DATA_ENTRY_TAG_P(dep); > > INT_SET(*tagp, ARCH_CONVERT, > (xfs_dir2_data_off_t)((char *)dep - (char *)block)); > > xfs_dir2_data_log_entry(tp, bp, dep); > > - INT_SET(blp[2 + i].hashval, ARCH_CONVERT, > xfs_da_hashname((char *)sfep->name, sfep->namelen)); > > + INT_SET(blp[2 + i].hashval, ARCH_CONVERT, > xfs_da_hashname((const uchar_t *)sfep->name, sfep->namelen)); > > INT_SET(blp[2 + i].address, ARCH_CONVERT, > XFS_DIR2_BYTE_TO_DATAPTR(mp, > > (char *)dep - > (char *)block)); > > offset = (int)((char *)(tagp + 1) - (char *)block); > > Index: xfsprogs/libdisk/fstype.c > > =================================================================== > > --- xfsprogs.orig/libdisk/fstype.c 2006-12-08 > 09:50:20.955342750 +1100 > > +++ xfsprogs/libdisk/fstype.c 2006-12-08 > 09:50:27.711765000 +1100 > > @@ -141,11 +141,11 @@ may_be_swap(const char *s) { > > > > /* rather weak necessary condition */ > > static int > > -may_be_adfs(const u_char *s) { > > - u_char *p; > > +may_be_adfs(const char *s) { > > + char *p; > > int sum; > > > > - p = (u_char *) s + 511; > > + p = (char *) s + 511; > > sum = 0; > > while(--p != s) > > sum = (sum >> 8) + (sum & 0xff) + *p; > > @@ -301,7 +301,7 @@ fstype(const char *device) { > > goto io_error; > > > > /* only a weak test */ > > - if (may_be_adfs((u_char *) &adfssb) > > + if (may_be_adfs((char *) &adfssb) > > && (adfsblksize(adfssb) >= 8 && > > adfsblksize(adfssb) <= 10)) > > type = "adfs"; > > Index: xfsprogs/libdisk/fstype.h > > =================================================================== > > --- xfsprogs.orig/libdisk/fstype.h 2006-12-08 > 09:49:45.061099500 +1100 > > +++ xfsprogs/libdisk/fstype.h 2006-12-08 > 09:51:00.657824000 +1100 > > @@ -38,8 +38,8 @@ > > #define MINIX2_SUPER_MAGIC 0x2468 /* minix v2, 14 char names */ > > #define MINIX2_SUPER_MAGIC2 0x2478 /* minix v2, 30 > char names */ > > struct minix_super_block { > > - u_char s_dummy[16]; > > - u_char s_magic[2]; > > + char s_dummy[16]; > > + char s_magic[2]; > > }; > > #define minixmagic(s) assemble2le(s.s_magic) > > > > @@ -63,8 +63,8 @@ struct hs_volume_descriptor { > > > > #define EXT_SUPER_MAGIC 0x137D > > struct ext_super_block { > > - u_char s_dummy[56]; > > - u_char s_magic[2]; > > + char s_dummy[56]; > > + char s_magic[2]; > > }; > > #define extmagic(s) assemble2le(s.s_magic) > > > > @@ -72,37 +72,37 @@ struct ext_super_block { > > #define EXT2_SUPER_MAGIC 0xEF53 > > #define EXT3_FEATURE_COMPAT_HAS_JOURNAL 0x0004 > > struct ext2_super_block { > > - u_char s_dummy1[56]; > > - u_char s_magic[2]; > > - u_char s_dummy2[34]; > > - u_char s_feature_compat[4]; > > - u_char s_feature_incompat[4]; > > - u_char s_feature_ro_compat[4]; > > - u_char s_uuid[16]; > > - u_char s_volume_name[16]; > > - u_char s_dummy3[88]; > > - u_char s_journal_inum[4]; /* ext3 only */ > > + char s_dummy1[56]; > > + char s_magic[2]; > > + char s_dummy2[34]; > > + char s_feature_compat[4]; > > + char s_feature_incompat[4]; > > + char s_feature_ro_compat[4]; > > + char s_uuid[16]; > > + char s_volume_name[16]; > > + char s_dummy3[88]; > > + char s_journal_inum[4]; /* ext3 only */ > > }; > > #define ext2magic(s) assemble2le(s.s_magic) > > > > struct reiserfs_super_block > > { > > - u_char s_block_count[4]; > > - u_char s_free_blocks[4]; > > - u_char s_root_block[4]; > > - u_char s_journal_block[4]; > > - u_char s_journal_dev[4]; > > - u_char s_orig_journal_size[4]; > > - u_char s_journal_trans_max[4]; > > - u_char s_journal_block_count[4]; > > - u_char s_journal_max_batch[4]; > > - u_char s_journal_max_commit_age[4]; > > - u_char s_journal_max_trans_age[4]; > > - u_char s_blocksize[2]; > > - u_char s_oid_maxsize[2]; > > - u_char s_oid_cursize[2]; > > - u_char s_state[2]; > > - u_char s_magic[12]; > > + char s_block_count[4]; > > + char s_free_blocks[4]; > > + char s_root_block[4]; > > + char s_journal_block[4]; > > + char s_journal_dev[4]; > > + char s_orig_journal_size[4]; > > + char s_journal_trans_max[4]; > > + char s_journal_block_count[4]; > > + char s_journal_max_batch[4]; > > + char s_journal_max_commit_age[4]; > > + char s_journal_max_trans_age[4]; > > + char s_blocksize[2]; > > + char s_oid_maxsize[2]; > > + char s_oid_cursize[2]; > > + char s_state[2]; > > + char s_magic[12]; > > }; > > #define REISERFS_SUPER_MAGIC_STRING "ReIsErFs" > > #define REISER2FS_SUPER_MAGIC_STRING "ReIsEr2Fs" > > @@ -112,9 +112,9 @@ struct reiserfs_super_block > > > > #define _XIAFS_SUPER_MAGIC 0x012FD16D > > struct xiafs_super_block { > > - u_char s_boot_segment[512]; /* 1st sector > reserved for boot */ > > - u_char s_dummy[60]; > > - u_char s_magic[4]; > > + char s_boot_segment[512]; /* 1st sector > reserved for boot */ > > + char s_dummy[60]; > > + char s_magic[4]; > > }; > > #define xiafsmagic(s) assemble4le(s.s_magic) > > > > @@ -122,16 +122,16 @@ struct xiafs_super_block { > > #define UFS_SUPER_MAGIC_LE 0x00011954 > > #define UFS_SUPER_MAGIC_BE 0x54190100 > > struct ufs_super_block { > > - u_char s_dummy[0x55c]; > > - u_char s_magic[4]; > > + char s_dummy[0x55c]; > > + char s_magic[4]; > > }; > > #define ufsmagic(s) assemble4le(s.s_magic) > > > > /* From Richard.Russon@ait.co.uk Wed Feb 24 08:05:27 1999 */ > > #define NTFS_SUPER_MAGIC "NTFS" > > struct ntfs_super_block { > > - u_char s_dummy[3]; > > - u_char s_magic[4]; > > + char s_dummy[3]; > > + char s_magic[4]; > > }; > > > > /* From inspection of a few FAT filesystems - aeb */ > > @@ -139,33 +139,33 @@ struct ntfs_super_block { > > it looks like a primary has some directory entries > where the extended > > has a partition table: IO.SYS, MSDOS.SYS, WINBOOT.SYS */ > > struct fat_super_block { > > - u_char s_dummy[3]; > > - u_char s_os[8]; /* "MSDOS5.0" or > "MSWIN4.0" or "MSWIN4.1" */ > > + char s_dummy[3]; > > + char s_os[8]; /* "MSDOS5.0" or > "MSWIN4.0" or "MSWIN4.1" */ > > /* mtools-3.9.4 writes "MTOOL394" */ > > - u_char s_dummy2[32]; > > - u_char s_label[11]; /* for DOS? */ > > - u_char s_fs[8]; /* "FAT12 " or "FAT16 > " or all zero */ > > + char s_dummy2[32]; > > + char s_label[11]; /* for DOS? */ > > + char s_fs[8]; /* "FAT12 " or "FAT16 > " or all zero */ > > /* OS/2 BM has "FAT " here. */ > > - u_char s_dummy3[9]; > > - u_char s_label2[11]; /* for Windows? */ > > - u_char s_fs2[8]; /* garbage or "FAT32 " */ > > + char s_dummy3[9]; > > + char s_label2[11]; /* for Windows? */ > > + char s_fs2[8]; /* garbage or "FAT32 " */ > > }; > > > > #define XFS_SUPER_MAGIC "XFSB" > > struct xfs_super_block { > > - u_char s_magic[4]; > > - u_char s_dummy[28]; > > - u_char s_uuid[16]; > > - u_char s_dummy2[60]; > > - u_char s_fname[12]; > > + char s_magic[4]; > > + char s_dummy[28]; > > + char s_uuid[16]; > > + char s_dummy2[60]; > > + char s_fname[12]; > > }; > > > > #define CRAMFS_SUPER_MAGIC 0x28cd3d45 > > #define CRAMFS_SUPER_MAGIC_BE 0x453dcd28 > > struct cramfs_super_block { > > - u_char s_magic[4]; > > - u_char s_dummy[12]; > > - u_char s_id[16]; > > + char s_magic[4]; > > + char s_dummy[12]; > > + char s_id[16]; > > }; > > #define cramfsmagic(s) assemble4le(s.s_magic) > > > > @@ -173,81 +173,81 @@ struct cramfs_super_block { > > #define HFSPLUS_SUPER_MAGIC 0x482B > > #define HFSPLUS_SUPER_VERSION 0x004 > > struct hfs_super_block { > > - u_char s_magic[2]; > > - u_char s_version[2]; > > + char s_magic[2]; > > + char s_version[2]; > > }; > > #define hfsmagic(s) assemble2le(s.s_magic) > > #define hfsversion(s) assemble2le(s.s_version) > > > > #define HPFS_SUPER_MAGIC 0xf995e849 > > struct hpfs_super_block { > > - u_char s_magic[4]; > > - u_char s_magic2[4]; > > + char s_magic[4]; > > + char s_magic2[4]; > > }; > > #define hpfsmagic(s) assemble4le(s.s_magic) > > > > struct adfs_super_block { > > - u_char s_dummy[448]; > > - u_char s_blksize[1]; > > - u_char s_dummy2[62]; > > - u_char s_checksum[1]; > > + char s_dummy[448]; > > + char s_blksize[1]; > > + char s_dummy2[62]; > > + char s_checksum[1]; > > }; > > #define adfsblksize(s) ((uint) s.s_blksize[0]) > > > > /* found in first 4 bytes of block 1 */ > > struct vxfs_super_block { > > - u_char s_magic[4]; > > + char s_magic[4]; > > }; > > #define vxfsmagic(s) assemble4le(s.s_magic) > > #define VXFS_SUPER_MAGIC 0xa501FCF5 > > > > struct jfs_super_block { > > char s_magic[4]; > > - u_char s_version[4]; > > - u_char s_dummy1[93]; > > + char s_version[4]; > > + char s_dummy1[93]; > > char s_fpack[11]; > > - u_char s_dummy2[24]; > > - u_char s_uuid[16]; > > + char s_dummy2[24]; > > + char s_uuid[16]; > > char s_label[16]; > > }; > > #define JFS_SUPER1_OFF 0x8000 > > #define JFS_MAGIC "JFS1" > > > > struct sysv_super_block { > > - u_char s_dummy1[504]; > > - u_char s_magic[4]; > > - u_char type[4]; > > + char s_dummy1[504]; > > + char s_magic[4]; > > + char type[4]; > > }; > > #define sysvmagic(s) assemble4le(s.s_magic) > > #define SYSV_SUPER_MAGIC 0xfd187e20 > > > > struct mdp_super_block { > > - u_char md_magic[4]; > > + char md_magic[4]; > > }; > > #define MD_SB_MAGIC 0xa92b4efc > > #define mdsbmagic(s) assemble4le(s.md_magic) > > > > struct ocfs_volume_header { > > - u_char minor_version[4]; > > - u_char major_version[4]; > > - u_char signature[128]; > > + char minor_version[4]; > > + char major_version[4]; > > + char signature[128]; > > }; > > > > struct ocfs_volume_label { > > - u_char disk_lock[48]; > > - u_char label[64]; > > - u_char label_len[2]; > > + char disk_lock[48]; > > + char label[64]; > > + char label_len[2]; > > }; > > > > #define ocfslabellen(o) assemble2le(o.label_len) > > #define OCFS_MAGIC "OracleCFS" > > > > static inline int > > -assemble2le(unsigned char *p) { > > +assemble2le(char *p) { > > return (p[0] | (p[1] << 8)); > > } > > > > static inline int > > -assemble4le(unsigned char *p) { > > +assemble4le(char *p) { > > return (p[0] | (p[1] << 8) | (p[2] << 16) | (p[3] << 24)); > > } > > Index: xfsprogs/db/check.c > > =================================================================== > > --- xfsprogs.orig/db/check.c 2006-12-08 > 09:55:43.307488500 +1100 > > +++ xfsprogs/db/check.c 2006-12-08 09:55:51.732015000 +1100 > > @@ -2299,7 +2299,7 @@ process_data_dir_v2( > > tag_err += INT_GET(*tagp, ARCH_CONVERT) != > (char *)dep - (char *)data; > > addr = XFS_DIR2_DB_OFF_TO_DATAPTR(mp, db, > > (char *)dep - (char *)data); > > - hash = libxfs_da_hashname((char *)dep->name, > dep->namelen); > > + hash = libxfs_da_hashname((uchar_t *)dep->name, > dep->namelen); > > dir_hash_add(hash, addr); > > ptr += XFS_DIR2_DATA_ENTSIZE(dep->namelen); > > count++; > > Index: xfsprogs/db/hash.c > > =================================================================== > > --- xfsprogs.orig/db/hash.c 2006-12-08 09:56:12.929339750 +1100 > > +++ xfsprogs/db/hash.c 2006-12-08 09:56:25.478124000 +1100 > > @@ -52,7 +52,7 @@ hash_f( > > { > > xfs_dahash_t hashval; > > > > - hashval = libxfs_da_hashname(argv[1], (int)strlen(argv[1])); > > + hashval = libxfs_da_hashname((uchar_t *)argv[1], > (int)strlen(argv[1])); > > dbprintf("0x%x\n", hashval); > > return 0; > > } > > Index: xfsprogs/mkfs/proto.c > > =================================================================== > > --- xfsprogs.orig/mkfs/proto.c 2006-12-08 > 09:57:08.404806750 +1100 > > +++ xfsprogs/mkfs/proto.c 2006-12-08 09:58:06.060410000 +1100 > > @@ -313,10 +313,10 @@ newdirent( > > int error; > > > > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > > - error = libxfs_dir2_createname(tp, pip, name, namelen, > > + error = libxfs_dir2_createname(tp, pip, > (uchar_t*)name, namelen, > > inum, first, > flist, total); > > else > > - error = libxfs_dir_createname(tp, pip, name, namelen, > > + error = libxfs_dir_createname(tp, pip, > (uchar_t*)name, namelen, > > inum, first, > flist, total); > > if (error) > > fail(_("directory createname error"), error); > > Index: xfsprogs/repair/phase6.c > > =================================================================== > > --- xfsprogs.orig/repair/phase6.c 2006-12-08 > 09:58:32.542065000 +1100 > > +++ xfsprogs/repair/phase6.c 2006-12-08 > 10:02:24.364553000 +1100 > > @@ -338,10 +338,12 @@ dir_createname(xfs_mount_t *mp, xfs_tran > > xfs_bmap_free_t *flist, xfs_extlen_t total) > > { > > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > > - return libxfs_dir2_createname(tp, pip, name, namelen, > > + return libxfs_dir2_createname(tp, pip, > > + (uchar_t *)name, namelen, > > inum, first, flist, total); > > else > > - return libxfs_dir_createname(tp, pip, name, namelen, > > + return libxfs_dir_createname(tp, pip, > > + (uchar_t *)name, namelen, > > inum, first, flist, total); > > } > > > > @@ -350,9 +352,11 @@ dir_lookup(xfs_mount_t *mp, xfs_trans_t > > int namelen, xfs_ino_t *inum) > > { > > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > > - return libxfs_dir2_lookup(tp, dp, name, namelen, inum); > > + return libxfs_dir2_lookup(tp, dp, > > + (uchar_t *)name, namelen, inum); > > else > > - return libxfs_dir_lookup(tp, dp, name, namelen, inum); > > + return libxfs_dir_lookup(tp, dp, > > + (uchar_t *)name, namelen, inum); > > } > > > > static int > > @@ -361,23 +365,12 @@ dir_replace(xfs_mount_t *mp, xfs_trans_t > > xfs_bmap_free_t *flist, xfs_extlen_t total) > > { > > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > > - return libxfs_dir2_replace(tp, dp, name, namelen, inum, > > + return libxfs_dir2_replace(tp, dp, > > + (uchar_t *)name, namelen, inum, > > firstblock, flist, total); > > else > > - return libxfs_dir_replace(tp, dp, name, namelen, inum, > > - firstblock, flist, total); > > -} > > - > > -static int > > -dir_removename(xfs_mount_t *mp, xfs_trans_t *tp, > xfs_inode_t *dp, char *name, > > - int namelen, xfs_ino_t inum, xfs_fsblock_t *firstblock, > > - xfs_bmap_free_t *flist, xfs_extlen_t total) > > -{ > > - if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > > - return libxfs_dir2_removename(tp, dp, name, > namelen, inum, > > - firstblock, flist, total); > > - else > > - return libxfs_dir_removename(tp, dp, name, > namelen, inum, > > + return libxfs_dir_replace(tp, dp, > > + (uchar_t *)name, namelen, inum, > > firstblock, flist, total); > > } > > > > @@ -387,10 +380,12 @@ dir_bogus_removename(xfs_mount_t *mp, xf > > xfs_extlen_t total, xfs_dahash_t hashval, int namelen) > > { > > if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) > > - return libxfs_dir2_bogus_removename(tp, dp, > name, firstblock, > > + return libxfs_dir2_bogus_removename(tp, dp, > > + (uchar_t *)name, firstblock, > > flist, total, hashval, namelen); > > else > > - return libxfs_dir_bogus_removename(tp, dp, > name, firstblock, > > + return libxfs_dir_bogus_removename(tp, dp, > > + (uchar_t *)name, firstblock, > > flist, total, hashval, namelen); > > } > > > > @@ -1863,7 +1858,7 @@ longform_dir2_rebuild( > > libxfs_trans_ihold(tp, ip); > > > > XFS_BMAP_INIT(&flist, &firstblock); > > - if ((error = libxfs_dir2_createname(tp, ip, > (char*)p->name, > > + if ((error = libxfs_dir2_createname(tp, ip, > (uchar_t *)p->name, > > p->namelen, p->inum, > &firstblock, &flist, > > nres))) { > > do_warn( > > > From owner-xfs@oss.sgi.com Sun Dec 10 21:55:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 10 Dec 2006 21:56:05 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBB5tqqw008239 for ; Sun, 10 Dec 2006 21:55:56 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21454; Mon, 11 Dec 2006 16:54:57 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id DC2F158C4C00; Mon, 11 Dec 2006 16:54:56 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 952227 - Severe lock contention in xfs_icsb_xxxx running Message-Id: <20061211055456.DC2F158C4C00@chook.melbourne.sgi.com> Date: Mon, 11 Dec 2006 16:54:56 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 9954 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 755 Lines: 20 Fix UP build breakage due to undefined m_icsb_mutex. Date: Mon Dec 11 16:54:27 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27692a fs/xfs/xfs_mount.h - 1.229 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.229&r2=text&tr2=1.228&f=h - Abstract m_icsb_mutex references into HAVE_PERCPU_SB dependent functions. fs/xfs/xfs_mount.c - 1.389 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.389&r2=text&tr2=1.388&f=h - Abstract m_icsb_mutex references into HAVE_PERCPU_SB dependent functions. From owner-xfs@oss.sgi.com Mon Dec 11 05:51:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 05:52:54 -0800 (PST) Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBBDpsqw002577 for ; Mon, 11 Dec 2006 05:51:57 -0800 Received: from tyo202.gate.nec.co.jp ([10.7.69.202]) by tyo200.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id kBBBw08c008212 for ; Mon, 11 Dec 2006 20:58:05 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.192]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id kBBBnfUU012974 for ; Mon, 11 Dec 2006 20:49:41 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id kBBBnfH14308 for xfs@oss.sgi.com; Mon, 11 Dec 2006 20:49:41 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id kBBBneA15158 for ; Mon, 11 Dec 2006 20:49:40 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20061211.205519.59300892 for ; Mon, 11 Dec 2006 20:55:19 +0900 Received: FROM tnessv1.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Mon Dec 11 20:55:19 2006 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by tnessv1.tnes.nec.co.jp (Postfix) with ESMTP id 83F99AE4B0 for ; Mon, 11 Dec 2006 20:48:52 +0900 (JST) Received: from TNESG9700 (TNESG9700.bsd.tnes.nec.co.jp [10.1.104.115]) by rifu.bsd.tnes.nec.co.jp (8.12.11/3.7W/BSD-TNES-MX01) with SMTP id kBBBnecL026668; Mon, 11 Dec 2006 20:49:40 +0900 To: xfs@oss.sgi.com Subject: [PATCH 2/2] Segmentation fault in xfsdump/xfsrestore Message-Id: <20061211204931k-ooizumi@rifu.bsd.tnes.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Kouta Ooizumi Date: Mon, 11 Dec 2006 20:49:31 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9955 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: k-ooizumi@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 3389 Lines: 124 Hi! xfsdump/xfsrestore causes segmentation fault when "-O options_file" is specified twice. Because mlog_fp is used before initialization. # xfsdump -L session -M label -O optfile -O optfile -f dump / This patch adds a new function, mlog_init0(). And it initializes three variables(mlog_fp, mlog_level_ss and mlog_qlockh). mlog_level_ss is initialized with MLOG_VERBOSE for the log output. Please patch "[PATCH 1/2] Fix the output message of xfsdump/xfsrestore" first. Signed-off-by: Kouta Ooizumi diff -up xfsdump-2.2.42-orig/common/main.c xfsdump-2.2.42/common/main.c --- xfsdump-2.2.42-orig/common/main.c 2006-11-17 14:17:38.000000000 +0900 +++ xfsdump-2.2.42/common/main.c 2006-11-30 15:26:22.000000000 +0900 @@ -199,6 +199,10 @@ main( int argc, char *argv[] ) rval = atexit(mlog_exit_flush); assert(rval == 0); + /* initialize message logging (stage 0) + */ + mlog_init0(); + /* pre-scan the command line for the option file option. * if found, create a new argv. */ diff -up xfsdump-2.2.42-orig/common/mlog.c xfsdump-2.2.42/common/mlog.c --- xfsdump-2.2.42-orig/common/mlog.c 2006-11-17 14:17:38.000000000 +0900 +++ xfsdump-2.2.42/common/mlog.c 2006-12-01 17:35:04.589000364 +0900 @@ -118,6 +118,25 @@ static int mlog_main_exit_code = -1; static rv_t mlog_main_exit_return = RV_NONE; static rv_t mlog_main_exit_hint = RV_NONE; +void +mlog_init0( void ) +{ + int i; + +#ifdef DUMP + mlog_fp = stderr; +#endif /* DUMP */ +#ifdef RESTORE + mlog_fp = stdout; +#endif /* RESTORE */ + + for( i = 0 ; i < MLOG_SS_CNT ; i++ ) { + mlog_level_ss[ i ] = MLOG_VERBOSE; + } + + mlog_qlockh = QLOCKH_NULL; +} + bool_t mlog_init1( intgen_t argc, char *argv[ ] ) { @@ -127,13 +146,6 @@ mlog_init1( intgen_t argc, char *argv[ ] size_t vsymcnt; intgen_t c; -#ifdef DUMP - mlog_fp = stderr; -#endif /* DUMP */ -#ifdef RESTORE - mlog_fp = stdout; -#endif /* RESTORE */ - /* initialize stream count. will be updated later by call to * mlog_tell_streamcnt( ), after drive layer has counted drives */ @@ -288,8 +300,6 @@ mlog_init1( intgen_t argc, char *argv[ ] } #endif /* DUMP */ - mlog_qlockh = QLOCKH_NULL; - return BOOL_TRUE; } diff -up xfsdump-2.2.42-orig/common/mlog.h xfsdump-2.2.42/common/mlog.h --- xfsdump-2.2.42-orig/common/mlog.h 2006-11-17 14:17:38.000000000 +0900 +++ xfsdump-2.2.42/common/mlog.h 2006-11-30 16:16:20.000000000 +0900 @@ -95,6 +95,7 @@ extern char *mlog_ss_names[ MLOG_SS_CNT /* initializes the mlog abstraction. split into two phases to * unravel some initialization sequencing problems. */ +extern void mlog_init0( void ); extern bool_t mlog_init1( intgen_t argc, char *argv[ ] ); extern bool_t mlog_init2( void ); diff -up xfsdump-2.2.42-orig/common/qlock.c xfsdump-2.2.42/common/qlock.c --- xfsdump-2.2.42-orig/common/qlock.c 2006-11-17 14:17:38.000000000 +0900 +++ xfsdump-2.2.42/common/qlock.c 2006-12-01 19:07:50.488832864 +0900 @@ -263,6 +263,8 @@ qlock_alloc( ix_t ord ) void qlock_lock( qlockh_t qlockh ) { + extern bool_t miniroot; + #ifdef HIDDEN qlock_t *qlockp = ( qlock_t * )qlockh; pid_t pid; @@ -271,10 +273,10 @@ qlock_lock( qlockh_t qlockh ) /* REFERENCED */ bool_t lockacquired; #endif - - /* sanity checks - */ - ASSERT( qlock_inited ); + + if ( ! qlock_inited ) { + qlock_init( miniroot ); + } /* bypass if miniroot */ From owner-xfs@oss.sgi.com Mon Dec 11 06:19:07 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 06:19:14 -0800 (PST) Received: from omx1.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBBEJ6qw006416 for ; Mon, 11 Dec 2006 06:19:07 -0800 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id kBBE5VDW000615 for ; Mon, 11 Dec 2006 08:05:31 -0600 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id kBBGrI5w013461 for ; Mon, 11 Dec 2006 08:53:18 -0800 Received: from [134.15.160.24] (vpn-emea-sw-emea-160-24.emea.sgi.com [134.15.160.24]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kBBE5Mbj64098514; Mon, 11 Dec 2006 06:05:23 -0800 (PST) Message-ID: <457D65A1.8030609@sgi.com> Date: Mon, 11 Dec 2006 14:05:21 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Steigerwald CC: linux-xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: invalid directory entry - bad magic number on inode References: <200612082100.00395.Martin@lichtvoll.de> In-Reply-To: <200612082100.00395.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 9956 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 7743 Lines: 208 Martin Steigerwald wrote: > Hello, > > today, I got a strange problem with XFS that seemed to affect only one > file. I stumbled upon it as I tried to remove the package serendipity on > my Debian mostly Etch/some Sid/probably some Experimental: > > ----------------------------------------------------------------------- > deepdance:~#130> aptitude purge serendipity > Paketlisten werden gelesen... Fertig > [...] > Entferne serendipity ... > dpkg: Fehler beim Bearbeiten von serendipity (--purge): > > Kann »/usr/share/serendipity/www/plugins/serendipity_event_livesearch/lang_pt_PT.inc.php« > nicht entfernen: Das Argument ist ungültig > Fehler traten auf beim Bearbeiten von: > serendipity > [...] > ----------------------------------------------------------------------- > > That means that the package could not removed cause that PHP file could > not be removed > > "Das Argument ist ungültig" means in english => "The argument is invalid" > > ----------------------------------------------------------------------- > deepdance:~#2> > ls -l /usr/share/serendipity/www/plugins/serendipity_event_livesearch/lang_pt_PT.inc.php > ls: /usr/share/serendipity/www/plugins/serendipity_event_livesearch/lang_pt_PT.inc.php: > Das Argument ist ungültig > deepdance:~#2> > ls -l /usr/share/serendipity/www/plugins/serendipity_event_livesearch/ > insgesamt 0 > ?--------- ? ? ? ? ? /usr/share/serendipity/www/plugins/serendipity_event_livesearch/lang_pt_PT.inc.php > ----------------------------------------------------------------------- > > Now that looks strange. I thought I better boot into SUSE 10.1 and check > my Debian root partition. > > ----------------------------------------------------------------------- > deepdance:~ # xfs_check /dev/hda5 > agi unlinked bucket 14 is 4110 in ag 0 (inode=4110) > agi unlinked bucket 25 is 12633 in ag 0 (inode=12633) > agi unlinked bucket 33 is 929 in ag 0 (inode=929) > [... more of that kinda usual stuff ...] > agi unlinked bucket 60 is 233532 in ag 9 (inode=37982268) > agi unlinked bucket 61 is 233533 in ag 9 (inode=37982269) > bad magic number 0 for inode 43113648 > agi unlinked bucket 0 is 74624 in ag 11 (inode=46211968) > agi unlinked bucket 1 is 74625 in ag 11 (inode=46211969) > [...] > agi unlinked bucket 57 is 47865 in ag 15 (inode=62962425) > agi unlinked bucket 58 is 164986 in ag 15 (inode=63079546) > block 10/73160 type unknown not expected > allocated inode 4110 has 0 link count > allocated inode 929 has 0 link count > [... more of that ...] > allocated inode 37982268 has 0 link count > allocated inode 37982269 has 0 link count > link count mismatch for inode 43113648 (name ?), nlink 0, counted 1 > allocated inode 46140958 has 0 link count > allocated inode 46137510 has 0 link count > [... more of that ...] > ----------------------------------------------------------------------- > > Hmmm, seems 43113648 is corrupted. > > As I need the laptop tomorrow for work I ran xfs_repair without much > further diagnostics. It seems to have fixed it the problem properly: > > ----------------------------------------------------------------------- > deepdance:~ # xfs_repair /dev/hda5 > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > - scan filesystem freespace and inode maps... > - found root inode chunk > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > error following ag 1 unlinked list > error following ag 2 unlinked list > error following ag 3 unlinked list > error following ag 8 unlinked list > error following ag 11 unlinked list > error following ag 12 unlinked list > error following ag 15 unlinked list > > ----------------------------------------------------------------------- > > Are those above harmless? I don't know, forwarding message for wider audience... > > ----------------------------------------------------------------------- > > Phase 3 - for each AG... > - scan and clear agi unlinked lists... > - process known inodes and perform inode discovery... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > - agno = 8 > - agno = 9 > - agno = 10 > bad magic number 0x0 on inode 43113648 > bad version number 0x2d on inode 43113648 > bad inode format in inode 43113648 > bad magic number 0x0 on inode 43113648, resetting magic number > bad version number 0x2d on inode 43113648, resetting version number > bad inode format in inode 43113648 > cleared inode 43113648 This inode was definitely corrupted, looks like it has been clobbered but not enough info to tell. > - agno = 11 > - agno = 12 > - agno = 13 > - agno = 14 > - agno = 15 > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - clear lost+found (if it exists) ... > - clearing existing "lost+found" inode > - marking entry "lost+found" to be deleted > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > - agno = 8 > - agno = 9 > - agno = 10 > entry "lang_pt_PT.inc.php" in shortform directory 43058698 references free > inode 43113648 > junking entry "lang_pt_PT.inc.php" in directory inode 43058698 > - agno = 11 > - agno = 12 > - agno = 13 > - agno = 14 > - agno = 15 > Phase 5 - rebuild AG headers and trees... > - reset superblock... > Phase 6 - check inode connectivity... > - resetting contents of realtime bitmap and summary inodes > - ensuring existence of lost+found directory > - traversing filesystem starting at / ... > rebuilding directory inode 128 > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > disconnected inode 929, moving to lost+found > disconnected inode 3366, moving to lost+found > [...more of those...] > ----------------------------------------------------------------------- > > Another run of xfs_check remains completely silent. All seems well again. The offending inode has been removed - fortunately that's what you were trying to do in the first place. > > Anyone any idea what that might have been? > > Unfortunately I cannot provide much further info. I do not even now when > this problem might have occured first. > > There are no traces of XFS problems in /var/log/syslog. > > I will do a backup now and then run a SMART offline check just to be > sure... > > Any hints on what I could try if it ever happens again? Suppose I can save > out the bad inode contents before I let xfs_repair fix it... If you see it again could you run xfs_check in verbose mode (ie xfs_check -v /dev/hda5 and xfs_check -v -i /dev/hda5)? > > Aside that so far no problems with XFS since 2.6.17.7 whatsoever ;-). > > This is on IBM ThinkPad T23 with 768 MB (it swapped out nevertheless... I > had two KDE sessions running and whatnot...) and this kernel: > > deepdance:~> cat /proc/version > Linux version 2.6.18.1-ck1-tp23-sws2-2.2.8 (root@deepdance) (gcc-Version > 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #1 PREEMPT Wed Oct 25 > 11:55:21 CEST 2006 > > It contains suspend2 patches by Nigel Cunningham and responsive ness > patches by Con Koliva. Apart from that it is vanilla. > > Regards, Thanks for reporting this problem. From owner-xfs@oss.sgi.com Mon Dec 11 06:46:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 06:46:59 -0800 (PST) Received: from tyo200.gate.nec.co.jp (TYO200.gate.nec.co.jp [210.143.35.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBBEkoqw009740 for ; Mon, 11 Dec 2006 06:46:52 -0800 Received: from tyo201.gate.nec.co.jp ([10.7.69.201]) by tyo200.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id kBBBr0mM006630 for ; Mon, 11 Dec 2006 20:53:14 +0900 (JST) Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id kBBBnNaL005457 for ; Mon, 11 Dec 2006 20:49:23 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id kBBBnMP24421 for xfs@oss.sgi.com; Mon, 11 Dec 2006 20:49:22 +0900 (JST) Received: from secsv3.tnes.nec.co.jp (tnesvc2.tnes.nec.co.jp [10.1.101.15]) by mailsv3.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with ESMTP id kBBBnLA14958 for ; Mon, 11 Dec 2006 20:49:21 +0900 (JST) Received: from tnesvc2.tnes.nec.co.jp ([10.1.101.15]) by secsv3.tnes.nec.co.jp (ExpressMail 5.10) with SMTP id 20061211.205500.54600892 for ; Mon, 11 Dec 2006 20:55:00 +0900 Received: FROM tnessv1.tnes.nec.co.jp BY tnesvc2.tnes.nec.co.jp ; Mon Dec 11 20:55:00 2006 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by tnessv1.tnes.nec.co.jp (Postfix) with ESMTP id 6F6F7AE4B0 for ; Mon, 11 Dec 2006 20:48:30 +0900 (JST) Received: from TNESG9700 (TNESG9700.bsd.tnes.nec.co.jp [10.1.104.115]) by rifu.bsd.tnes.nec.co.jp (8.12.11/3.7W/BSD-TNES-MX01) with SMTP id kBBBnHlq026659; Mon, 11 Dec 2006 20:49:17 +0900 To: xfs@oss.sgi.com Subject: [PATCH 1/2] Fix the output message of xfsdump/xfsrestore Message-Id: <20061211204909k-ooizumi@rifu.bsd.tnes.nec.co.jp> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Kouta Ooizumi Date: Mon, 11 Dec 2006 20:49:08 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 9957 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: k-ooizumi@tnes.nec.co.jp Precedence: bulk X-list: xfs Content-Length: 19000 Lines: 566 Hi! The attached patch fixes the output message of xfsdump/xfsrestore. When you set a wrong option argument, this issue happens. e.g) # xfsdump -L session -M label -l 10 -f dump / : : xfsdump: ERROR: - argument must be between 0 and 9 ^ : Signed-off-by: Kouta Ooizumi diff -uprN xfsdump-2.2.42-orig/common/drive.c xfsdump-2.2.42/common/drive.c --- xfsdump-2.2.42-orig/common/drive.c 2006-06-20 15:51:26.000000000 +0900 +++ xfsdump-2.2.42/common/drive.c 2006-12-11 13:58:37.483966901 +0900 @@ -109,7 +109,7 @@ drive_init1( int argc, char *argv[ ], bo mlog( MLOG_NORMAL, _( "too many -%c arguments: " "maximum is %d when running in miniroot\n"), - optopt, + GETOPT_DUMPDEST, 1 ); usage( ); return BOOL_FALSE; @@ -146,7 +146,7 @@ drive_init1( int argc, char *argv[ ], bo if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL, _("-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } diff -uprN xfsdump-2.2.42-orig/common/drive_minrmt.c xfsdump-2.2.42/common/drive_minrmt.c --- xfsdump-2.2.42-orig/common/drive_minrmt.c 2006-06-21 13:53:11.000000000 +0900 +++ xfsdump-2.2.42/common/drive_minrmt.c 2006-12-11 13:58:37.490965845 +0900 @@ -450,7 +450,7 @@ ds_match( int argc, char *argv[], drive_ if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, _("-%c argument missing\n"), - optopt ); + c ); return -10; } cmdlineblksize = ( u_int32_t )atoi( optarg ); @@ -527,7 +527,7 @@ ds_instantiate( int argc, char *argv[], if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, _("-%c argument missing\n"), - optopt ); + c ); return BOOL_FALSE; } contextp->dc_ringlen = ( size_t )atoi( optarg ); @@ -537,7 +537,7 @@ ds_instantiate( int argc, char *argv[], mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, _("-%c argument must be " "between %u and %u: ignoring %u\n"), - optopt, + c, RINGLEN_MIN, RINGLEN_MAX, contextp->dc_ringlen ); @@ -566,7 +566,7 @@ ds_instantiate( int argc, char *argv[], if ( ! optarg || optarg [ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, _("-%c argument missing\n"), - optopt ); + c ); return BOOL_FALSE; } contextp->dc_filesz = (off64_t)atoi( optarg ) * 1024 * 1024; @@ -574,7 +574,7 @@ ds_instantiate( int argc, char *argv[], mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, _("-%c argument must be a " "positive number (MB): ignoring %u\n"), - optopt, + c, contextp->dc_filesz ); return BOOL_FALSE; } diff -uprN xfsdump-2.2.42-orig/common/drive_scsitape.c xfsdump-2.2.42/common/drive_scsitape.c --- xfsdump-2.2.42-orig/common/drive_scsitape.c 2006-06-20 15:51:26.000000000 +0900 +++ xfsdump-2.2.42/common/drive_scsitape.c 2006-12-11 13:58:37.485966600 +0900 @@ -609,7 +609,7 @@ ds_instantiate( int argc, char *argv[], if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, _("-%c argument missing\n"), - optopt ); + c ); return BOOL_FALSE; } contextp->dc_ringlen = ( size_t )atoi( optarg ); @@ -619,7 +619,7 @@ ds_instantiate( int argc, char *argv[], mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, _("-%c argument must be " "between %u and %u: ignoring %u\n"), - optopt, + c, RINGLEN_MIN, RINGLEN_MAX, contextp->dc_ringlen ); @@ -642,7 +642,7 @@ ds_instantiate( int argc, char *argv[], if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, _("-%c argument missing\n"), - optopt ); + c ); return -10; } cmdlineblksize = ( u_int32_t )atoi( optarg ); @@ -655,7 +655,7 @@ ds_instantiate( int argc, char *argv[], if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_WARNING | MLOG_DRIVE, _("-%c argument missing\n"), - optopt ); + c ); return BOOL_FALSE; } /* given in Mb */ @@ -664,7 +664,7 @@ ds_instantiate( int argc, char *argv[], mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_DRIVE, _("-%c argument must be a " "positive number (Mb): ignoring %u\n"), - optopt, + c, contextp->dc_filesz ); return BOOL_FALSE; } diff -uprN xfsdump-2.2.42-orig/common/global.c xfsdump-2.2.42/common/global.c --- xfsdump-2.2.42-orig/common/global.c 2006-06-20 15:51:26.000000000 +0900 +++ xfsdump-2.2.42/common/global.c 2006-12-11 13:58:37.486966449 +0900 @@ -127,8 +127,8 @@ global_hdr_alloc( intgen_t argc, char *a mlog( MLOG_NORMAL, _("too many -%c arguments: " "\"-%c %s\" already given\n"), - optopt, - optopt, + c, + c, dumplabel ); usage( ); return 0; @@ -136,7 +136,7 @@ global_hdr_alloc( intgen_t argc, char *a if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _("-%c argument missing\n"), - optopt ); + c ); usage( ); return 0; } @@ -147,14 +147,14 @@ global_hdr_alloc( intgen_t argc, char *a if ( ! uuid_is_null( ghdrp->gh_dumpid )) { mlog( MLOG_NORMAL | MLOG_ERROR, _("too many -%c arguments\n"), - optopt ); + c ); usage( ); return 0; } if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _("-%c argument missing\n"), - optopt ); + c ); usage( ); return 0; } @@ -162,7 +162,7 @@ global_hdr_alloc( intgen_t argc, char *a if ( ! uuid_parse( optarg, ghdrp->gh_dumpid ) ) { mlog( MLOG_NORMAL | MLOG_ERROR, _("-%c argument not a valid uuid\n"), - optopt ); + c ); usage( ); return 0; } @@ -176,7 +176,7 @@ global_hdr_alloc( intgen_t argc, char *a if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _("-%c argument missing\n"), - optopt ); + c ); usage( ); return 0; } diff -uprN xfsdump-2.2.42-orig/common/main.c xfsdump-2.2.42/common/main.c --- xfsdump-2.2.42-orig/common/main.c 2006-06-20 15:51:26.000000000 +0900 +++ xfsdump-2.2.42/common/main.c 2006-12-11 13:58:37.487966298 +0900 @@ -233,7 +233,7 @@ main( int argc, char *argv[] ) if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_NOLOCK, _("-%c argument missing\n"), - optopt ); + c ); usage( ); return mlog_exit(EXIT_ERROR, RV_OPT); } @@ -244,7 +244,7 @@ main( int argc, char *argv[] ) errno == ERANGE ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_NOLOCK, _("-%c argument (%s) invalid\n"), - optopt, + c, optarg ); usage( ); return mlog_exit(EXIT_ERROR, RV_OPT); @@ -255,7 +255,7 @@ main( int argc, char *argv[] ) if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_NOLOCK, _("-%c argument missing\n"), - optopt ); + c ); usage( ); return mlog_exit(EXIT_ERROR, RV_OPT); } @@ -266,7 +266,7 @@ main( int argc, char *argv[] ) errno == ERANGE ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_NOLOCK, _("-%c argument (%s) invalid\n"), - optopt, + c, optarg ); usage( ); return mlog_exit(EXIT_ERROR, RV_OPT); @@ -284,7 +284,7 @@ main( int argc, char *argv[] ) if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_NOLOCK, _("-%c argument missing\n"), - optopt ); + c ); usage( ); return mlog_exit(EXIT_ERROR, RV_OPT); } @@ -1222,14 +1222,14 @@ loadoptfile( intgen_t *argcp, char ***ar if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_NOLOCK, _("-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } if ( optfilename ) { mlog( MLOG_NORMAL | MLOG_ERROR | MLOG_NOLOCK, _("-%c allowed only once\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } diff -uprN xfsdump-2.2.42-orig/common/media.c xfsdump-2.2.42/common/media.c --- xfsdump-2.2.42-orig/common/media.c 2006-06-20 15:51:26.000000000 +0900 +++ xfsdump-2.2.42/common/media.c 2006-12-11 13:58:37.484966750 +0900 @@ -107,8 +107,8 @@ media_create( int argc, char *argv[ ], d mlog( MLOG_NORMAL, _("too many -%c arguments: " "\"-%c %s\" already given\n"), - optopt, - optopt, + c, + c, medialabel ); usage( ); return 0; @@ -116,7 +116,7 @@ media_create( int argc, char *argv[ ], d if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL, _("-%c argument missing\n"), - optopt ); + c ); usage( ); return 0; } diff -uprN xfsdump-2.2.42-orig/common/mlog.c xfsdump-2.2.42/common/mlog.c --- xfsdump-2.2.42-orig/common/mlog.c 2006-06-20 15:51:26.000000000 +0900 +++ xfsdump-2.2.42/common/mlog.c 2006-12-11 13:58:37.488966147 +0900 @@ -179,7 +179,7 @@ mlog_init1( intgen_t argc, char *argv[ ] fprintf( stderr, _("%s: -%c argument missing\n"), progname, - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -195,7 +195,7 @@ mlog_init1( intgen_t argc, char *argv[ ] fprintf( stderr, _("%s: -%c argument invalid\n"), progname, - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -210,7 +210,7 @@ mlog_init1( intgen_t argc, char *argv[ ] "%s requires a " "verbosity value\n"), progname, - optopt, + c, mlog_ss_names[ suboptix ] ); usage( ); return BOOL_FALSE; @@ -225,7 +225,7 @@ mlog_init1( intgen_t argc, char *argv[ ] "does not require " "a value\n"), progname, - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -238,7 +238,7 @@ mlog_init1( intgen_t argc, char *argv[ ] _("%s: -%c argument " "invalid\n"), progname, - optopt ); + c ); usage( ); return BOOL_FALSE; } diff -uprN xfsdump-2.2.42-orig/dump/content.c xfsdump-2.2.42/dump/content.c --- xfsdump-2.2.42-orig/dump/content.c 2006-06-20 15:51:26.000000000 +0900 +++ xfsdump-2.2.42/dump/content.c 2006-12-11 13:58:37.458970672 +0900 @@ -598,7 +598,7 @@ content_init( intgen_t argc, if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -607,7 +607,7 @@ content_init( intgen_t argc, mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument must be " "between 0 and %d\n"), - optopt, + c, LEVEL_MAX ); usage( ); return BOOL_FALSE; @@ -617,7 +617,7 @@ content_init( intgen_t argc, if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -625,7 +625,7 @@ content_init( intgen_t argc, mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument (subtree) " "must be a relative pathname\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -635,7 +635,7 @@ content_init( intgen_t argc, if ( ! optarg || optarg [ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -645,7 +645,7 @@ content_init( intgen_t argc, ( maxdumpfilesize == ULONGLONG_MAX && errno == ERANGE ) ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument is not a valid file size\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -667,7 +667,7 @@ content_init( intgen_t argc, if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -684,7 +684,7 @@ content_init( intgen_t argc, if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -694,7 +694,7 @@ content_init( intgen_t argc, mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument not a valid " "dump session id\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -1662,14 +1662,14 @@ baseuuidbypass: mlog( MLOG_NORMAL, _( "more -%c arguments " "than number of drives\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } diff -uprN xfsdump-2.2.42-orig/restore/content.c xfsdump-2.2.42/restore/content.c --- xfsdump-2.2.42-orig/restore/content.c 2006-06-20 15:51:26.000000000 +0900 +++ xfsdump-2.2.42/restore/content.c 2006-12-11 13:58:37.474968259 +0900 @@ -927,7 +927,7 @@ content_init( intgen_t argc, char *argv[ if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -935,7 +935,7 @@ content_init( intgen_t argc, char *argv[ mlog( MLOG_NORMAL | MLOG_ERROR, _( "unable to get status of -%c argument %s:" " %s\n"), - optopt, + c, optarg, strerror( errno )); return BOOL_FALSE; @@ -953,7 +953,7 @@ content_init( intgen_t argc, char *argv[ if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -964,7 +964,7 @@ content_init( intgen_t argc, char *argv[ mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument %s is an " "invalid pathname\n"), - optopt, + c, optarg ); usage( ); return BOOL_FALSE; @@ -981,7 +981,7 @@ content_init( intgen_t argc, char *argv[ if ( rval ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "cannot stat -%c argument %s (%s): %s\n"), - optopt, + c, optarg, tranp->t_hkdir, strerror( errno )); @@ -992,7 +992,7 @@ content_init( intgen_t argc, char *argv[ mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument %s (%s) " "is not a directory\n"), - optopt, + c, optarg, tranp->t_hkdir ); usage( ); @@ -1005,8 +1005,8 @@ content_init( intgen_t argc, char *argv[ mlog( MLOG_NORMAL | MLOG_ERROR, _( "too many -%c arguments: " "\"-%c %s\" already given\n"), - optopt, - optopt, + c, + c, tranp->t_reqdumplab ); usage( ); return BOOL_FALSE; @@ -1014,7 +1014,7 @@ content_init( intgen_t argc, char *argv[ if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -1023,7 +1023,7 @@ content_init( intgen_t argc, char *argv[ sizeofmember( pers_t, s.dumplab )) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument %s too long: max is %d\n"), - optopt, + c, optarg, sizeofmember( pers_t, s.dumplab )); usage( ); @@ -1036,21 +1036,21 @@ content_init( intgen_t argc, char *argv[ if ( tranp->t_reqdumpidvalpr ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "too many -%c arguments\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } if (uuid_parse( optarg, tranp->t_reqdumpid ) < 0 ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument not a valid uuid\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -1065,14 +1065,14 @@ content_init( intgen_t argc, char *argv[ optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } if ( optarg[ 0 ] == '/' ) { mlog( MLOG_NORMAL, _( "-%c argument must be relative\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } @@ -1111,7 +1111,7 @@ content_init( intgen_t argc, char *argv[ if ( ! optarg || optarg[ 0 ] == '-' ) { mlog( MLOG_NORMAL | MLOG_ERROR, _( "-%c argument missing\n"), - optopt ); + c ); usage( ); return BOOL_FALSE; } From owner-xfs@oss.sgi.com Mon Dec 11 06:54:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 06:54:45 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBBEsLqw010849 for ; Mon, 11 Dec 2006 06:54:34 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 7FE3E18CFB139; Mon, 11 Dec 2006 08:53:28 -0600 (CST) Message-ID: <457D70E4.8090301@sandeen.net> Date: Mon, 11 Dec 2006 08:53:24 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Chris Wedgwood CC: Dennis Varouxis , xfs@oss.sgi.com Subject: Re: Unable to mount XFS partition on Sun Ultra/Linux 2.6.17 - Function not implemented References: <457997E6.60900@sandeen.net> <20061210090454.GB6192@tuatara.stupidest.org> In-Reply-To: <20061210090454.GB6192@tuatara.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9958 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 530 Lines: 23 Chris Wedgwood wrote: > On Fri, Dec 08, 2006 at 10:50:46AM -0600, Eric Sandeen wrote: > >> Looks like version one directories, recently ripped out of Linux... > > there should be a prinkt to this effect for these cases > There was some mount error message logic that was backwards, that might be why there was none. see: TAKE 958469 - Quiet mounts on XFS aren't The XFS quiet mount logic was inverted making quiet mounts noisy and vice versa. Fix it. Haven't looked too closely but that may well be the problem. -Eric From owner-xfs@oss.sgi.com Mon Dec 11 12:12:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 12:12:12 -0800 (PST) Received: from mail.lichtvoll.de (13.unused.teamix.net [194.150.191.13] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBBKC2qw015802 for ; Mon, 11 Dec 2006 12:12:03 -0800 Received: from localhost (dslb-084-056-110-111.pools.arcor-ip.net [84.56.110.111]) by mail.lichtvoll.de (Postfix) with ESMTP id 16A6642DFD; Mon, 11 Dec 2006 21:11:11 +0100 (CET) From: Martin Steigerwald To: linux-xfs@oss.sgi.com, lachlan@sgi.com Subject: Re: invalid directory entry - bad magic number on inode Date: Mon, 11 Dec 2006 21:11:07 +0100 User-Agent: KMail/1.9.5 Cc: xfs-dev@sgi.com References: <200612082100.00395.Martin@lichtvoll.de> <457D65A1.8030609@sgi.com> In-Reply-To: <457D65A1.8030609@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612112111.08209.Martin@lichtvoll.de> X-archive-position: 9961 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 1036 Lines: 27 Am Montag 11 Dezember 2006 15:05 schrieb Lachlan McIlroy: > > Any hints on what I could try if it ever happens again? Suppose I can > > save out the bad inode contents before I let xfs_repair fix it... > > If you see it again could you run xfs_check in verbose mode (ie > xfs_check -v /dev/hda5 and xfs_check -v -i /dev/hda5)? Hello Lachlan, thanks for the hints. So far it didn't occur again (at least not that I am aware of) - well I don't expect it to happen often and am not really sure whether it will happen again at all. > Thanks for reporting this problem. You are welcome. Without further info reporting it to the bugtracker doesn't make much sense to me. I will keep an eye on it. If it happens again, I will try the hints you gave me. I run xfs_check anyway and thus can easily give it a "-v >xfs_check.txt". I thought I would have to use xfs_db stuff to get further info. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Mon Dec 11 12:55:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 12:55:35 -0800 (PST) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.25]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBBKtTqw024564 for ; Mon, 11 Dec 2006 12:55:29 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id kBBKerID001420 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Dec 2006 12:40:53 -0800 Received: from akpm.corp.google.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id kBBKeqDe006680; Mon, 11 Dec 2006 12:40:52 -0800 Date: Mon, 11 Dec 2006 12:40:52 -0800 From: Andrew Morton To: Dmitriy Monakhov Cc: linux-kernel@vger.kernel.org, Linux Memory Management , , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect error handling inside generic_file_direct_write Message-Id: <20061211124052.144e69a0.akpm@osdl.org> In-Reply-To: <87k60y1rq4.fsf@sw.ru> References: <87k60y1rq4.fsf@sw.ru> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.162 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9962 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: xfs Content-Length: 2287 Lines: 60 On Mon, 11 Dec 2006 16:34:27 +0300 Dmitriy Monakhov wrote: > OpenVZ team has discovered error inside generic_file_direct_write() > If generic_file_direct_IO() has fail (ENOSPC condition) it may have instantiated > a few blocks outside i_size. And fsck will complain about wrong i_size > (ext2, ext3 and reiserfs interpret i_size and biggest block difference as error), > after fsck will fix error i_size will be increased to the biggest block, > but this blocks contain gurbage from previous write attempt, this is not > information leak, but its silence file data corruption. > We need truncate any block beyond i_size after write have failed , do in simular > generic_file_buffered_write() error path. > > Exampe: > open("mnt2/FILE3", O_WRONLY|O_CREAT|O_DIRECT, 0666) = 3 > write(3, "aaaaaa"..., 4096) = -1 ENOSPC (No space left on device) > > stat mnt2/FILE3 > File: `mnt2/FILE3' > Size: 0 Blocks: 4 IO Block: 4096 regular empty file > >>>>>>>>>>>>>>>>>>>>>>^^^^^^^^^^ file size is less than biggest block idx > Device: 700h/1792d Inode: 14 Links: 1 > Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) > > fsck.ext2 -f -n mnt1/fs_img > Pass 1: Checking inodes, blocks, and sizes > Inode 14, i_size is 0, should be 2048. Fix? no > > Signed-off-by: Dmitriy Monakhov > ---------- > > diff --git a/mm/filemap.c b/mm/filemap.c > index 7b84dc8..bf7cf6c 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -2041,6 +2041,14 @@ generic_file_direct_write(struct kiocb * > mark_inode_dirty(inode); > } > *ppos = end; > + } else if (written < 0) { > + loff_t isize = i_size_read(inode); > + /* > + * generic_file_direct_IO() may have instantiated a few blocks > + * outside i_size. Trim these off again. > + */ > + if (pos + count > isize) > + vmtruncate(inode, isize); > } > XFS (at least) can call generic_file_direct_write() with i_mutex not held. And vmtruncate() expects i_mutex to be held. I guess a suitable solution would be to push this problem back up to the callers: let them decide whether to run vmtruncate() and if so, to ensure that i_mutex is held. The existence of generic_file_aio_write_nolock() makes that rather messy though. From owner-xfs@oss.sgi.com Mon Dec 11 15:23:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 15:23:09 -0800 (PST) Received: from netcenter.hu (ns.netcenter.hu [195.228.254.57]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBBNMxqw008438 for ; Mon, 11 Dec 2006 15:23:02 -0800 Received: from dcccs (dsl5401D062.pool.t-online.hu [84.1.208.98]) by netcenter.hu (8.13.4/8.12.8) with SMTP id kBBMxBAm021098; Mon, 11 Dec 2006 23:59:11 +0100 Message-ID: <003701c71d78$33ed28d0$0400a8c0@dcccs> From: =?iso-8859-2?Q?Haar_J=E1nos?= To: Cc: Subject: xfslogd-spinlock bug? Date: Tue, 12 Dec 2006 00:00:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-archive-position: 9963 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 5228 Lines: 128 Hello, list, I am the "big red button men" with the one big 14TB xfs, if somebody can remember me. :-) Now i found something in the 2.6.16.18, and try the 2.6.18.4, and the 2.6.19, but the bug still exists: Dec 11 22:47:21 dy-base BUG: spinlock bad magic on CPU#3, xfslogd/3/317 Dec 11 22:47:21 dy-base general protection fault: 0000 [1] Dec 11 22:47:21 dy-base SMP Dec 11 22:47:21 dy-base Dec 11 22:47:21 dy-base CPU 3 Dec 11 22:47:21 dy-base Dec 11 22:47:21 dy-base Modules linked in: Dec 11 22:47:21 dy-base nbd Dec 11 22:47:21 dy-base rd Dec 11 22:47:21 dy-base netconsole Dec 11 22:47:21 dy-base e1000 Dec 11 22:47:21 dy-base video Dec 11 22:47:21 dy-base Dec 11 22:47:21 dy-base Pid: 317, comm: xfslogd/3 Not tainted 2.6.19 #1 Dec 11 22:47:21 dy-base RIP: 0010:[] Dec 11 22:47:21 dy-base [] spin_bug+0x69/0xdf Dec 11 22:47:21 dy-base RSP: 0018:ffff81011fb89bc0 EFLAGS: 00010002 Dec 11 22:47:21 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 Dec 11 22:47:21 dy-base RDX: ffffffff808137a0 RSI: 0000000000000082 RDI: 0000000100000000 Dec 11 22:47:21 dy-base RBP: ffff81011fb89be0 R08: 0000000000026a70 R09: 000000006b6b6b6b Dec 11 22:47:21 dy-base R10: 0000000000000082 R11: ffff81000584d380 R12: ffff8100db92ad80 Dec 11 22:47:21 dy-base R13: ffffffff80642dc6 R14: 0000000000000000 R15: 0000000000000003 Dec 11 22:47:21 dy-base FS: 0000000000000000(0000) GS:ffff81011fc76b90(0000) knlGS:0000000000000000 Dec 11 22:47:21 dy-base CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Dec 11 22:47:21 dy-base CR2: 00002ba007700000 CR3: 0000000108c05000 CR4: 00000000000006e0 Dec 11 22:47:21 dy-base Process xfslogd/3 (pid: 317, threadinfo ffff81011fb88000, task ffff81011fa7f830) Dec 11 22:47:21 dy-base Stack: Dec 11 22:47:21 dy-base ffff81011fb89be0 Dec 11 22:47:21 dy-base ffff8100db92ad80 Dec 11 22:47:21 dy-base 0000000000000000 Dec 11 22:47:21 dy-base 0000000000000000 Dec 11 22:47:21 dy-base Dec 11 22:47:21 dy-base ffff81011fb89c10 Dec 11 22:47:21 dy-base ffffffff803f3bdc Dec 11 22:47:21 dy-base 0000000000000282 Dec 11 22:47:21 dy-base 0000000000000000 Dec 11 22:47:21 dy-base Dec 11 22:47:21 dy-base 0000000000000000 Dec 11 22:47:21 dy-base 0000000000000000 Dec 11 22:47:21 dy-base ffff81011fb89c30 Dec 11 22:47:21 dy-base ffffffff805e7f2b Dec 11 22:47:21 dy-base Dec 11 22:47:21 dy-base Call Trace: Dec 11 22:47:21 dy-base [] _raw_spin_lock+0x23/0xf1 Dec 11 22:47:21 dy-base [] _spin_lock_irqsave+0x11/0x18 Dec 11 22:47:21 dy-base [] __wake_up+0x22/0x50 Dec 11 22:47:21 dy-base [] xfs_buf_unpin+0x21/0x23 Dec 11 22:47:21 dy-base [] xfs_buf_item_unpin+0x2e/0xa6 Dec 11 22:47:21 dy-base [] xfs_trans_chunk_committed+0xc3/0xf7 Dec 11 22:47:21 dy-base [] xfs_trans_committed+0x49/0xde Dec 11 22:47:21 dy-base [] xlog_state_do_callback+0x185/0x33f Dec 11 22:47:21 dy-base [] xlog_iodone+0x104/0x131 Dec 11 22:47:22 dy-base [] xfs_buf_iodone_work+0x1a/0x3e Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 Dec 11 22:47:22 dy-base [] run_workqueue+0xa8/0xf8 Dec 11 22:47:22 dy-base [] xfs_buf_iodone_work+0x0/0x3e Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 Dec 11 22:47:22 dy-base [] worker_thread+0xfb/0x134 Dec 11 22:47:22 dy-base [] default_wake_function+0x0/0xf Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 Dec 11 22:47:22 dy-base [] kthread+0xd8/0x10b Dec 11 22:47:22 dy-base [] schedule_tail+0x45/0xa6 Dec 11 22:47:22 dy-base [] child_rip+0xa/0x12 Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 Dec 11 22:47:22 dy-base [] kthread+0x0/0x10b Dec 11 22:47:22 dy-base [] child_rip+0x0/0x12 Dec 11 22:47:22 dy-base Dec 11 22:47:22 dy-base Dec 11 22:47:22 dy-base Code: Dec 11 22:47:22 dy-base 8b Dec 11 22:47:22 dy-base 83 Dec 11 22:47:22 dy-base 0c Dec 11 22:47:22 dy-base 01 Dec 11 22:47:22 dy-base 00 Dec 11 22:47:22 dy-base 00 Dec 11 22:47:22 dy-base 48 Dec 11 22:47:22 dy-base 8d Dec 11 22:47:22 dy-base 8b Dec 11 22:47:22 dy-base 98 Dec 11 22:47:22 dy-base 02 Dec 11 22:47:22 dy-base 00 Dec 11 22:47:22 dy-base 00 Dec 11 22:47:22 dy-base 41 Dec 11 22:47:22 dy-base 8b Dec 11 22:47:22 dy-base 54 Dec 11 22:47:22 dy-base 24 Dec 11 22:47:22 dy-base 04 Dec 11 22:47:22 dy-base 41 Dec 11 22:47:22 dy-base 89 Dec 11 22:47:22 dy-base Dec 11 22:47:22 dy-base RIP Dec 11 22:47:22 dy-base [] spin_bug+0x69/0xdf Dec 11 22:47:22 dy-base RSP Dec 11 22:47:22 dy-base Dec 11 22:47:22 dy-base Kernel panic - not syncing: Fatal exception Dec 11 22:47:22 dy-base Dec 11 22:47:22 dy-base Rebooting in 5 seconds.. After this, sometimes the server reboots normally, but sometimes hangs, no console, no sysreq, no nothing. This is a "simple" crash, no "too much" data lost, or else. Can somebody help me to tracking down the problem? Thanks, Janos Haar From owner-xfs@oss.sgi.com Mon Dec 11 15:30:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 15:30:29 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBBNUJqw009674 for ; Mon, 11 Dec 2006 15:30:22 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13920; Tue, 12 Dec 2006 10:29:20 +1100 Message-ID: <457DEA62.8020008@sgi.com> Date: Tue, 12 Dec 2006 10:31:46 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: linux-xfs@oss.sgi.com Subject: TAKE 959109: [clone 958105] A mmap call of an offline file does not generate a dmapi event. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9964 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 1181 Lines: 27 Fix XFS to include DMAPI specific code in both cases of including DMAPI, as a module or statically linked with the kernel. Date: Tue Dec 12 10:21:45 AEDT 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: dgc Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27696a fs/xfs/linux-2.6/xfs_linux.h - 1.152 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.152&r2=text&tr2=1.151&f=h - pv 959109, rv dgc - define HAVE_DMAPI for modular (CONFIG_XFS_DMAPI_MODULE) and static link (CONFIG_XFS_DMAPI) of dmapi. fs/xfs/linux-2.6/xfs_file.c - 1.147 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_file.c.diff?r1=text&tr1=1.147&r2=text&tr2=1.146&f=h fs/xfs/linux-2.4/xfs_file.c - 1.130 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_file.c.diff?r1=text&tr1=1.130&r2=text&tr2=1.129&f=h - pv 959109, rv dgc - CONFIG_XFS_DMAPI is used as both - environment var and compile time def. Change it to HAVE_DMAPI fro compile time def. From owner-xfs@oss.sgi.com Mon Dec 11 16:41:06 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 16:41:16 -0800 (PST) Received: from omx1.sgi.com (omx1.americas.sgi.com [198.149.16.13]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBC0f4qw022399 for ; Mon, 11 Dec 2006 16:41:05 -0800 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id kBC0eEDW026110 for ; Mon, 11 Dec 2006 18:40:14 -0600 Received: from [134.15.160.4] (vpn-emea-sw-emea-160-4.emea.sgi.com [134.15.160.4]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kBC0eBbj64217276; Mon, 11 Dec 2006 16:40:12 -0800 (PST) Message-ID: <457DFA6A.9050200@sgi.com> Date: Tue, 12 Dec 2006 00:40:10 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Steigerwald CC: linux-xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: invalid directory entry - bad magic number on inode References: <200612082100.00395.Martin@lichtvoll.de> <457D65A1.8030609@sgi.com> <200612112111.08209.Martin@lichtvoll.de> In-Reply-To: <200612112111.08209.Martin@lichtvoll.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 9965 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 1070 Lines: 32 Martin Steigerwald wrote: > Am Montag 11 Dezember 2006 15:05 schrieb Lachlan McIlroy: > > >>>Any hints on what I could try if it ever happens again? Suppose I can >>>save out the bad inode contents before I let xfs_repair fix it... >> >>If you see it again could you run xfs_check in verbose mode (ie >>xfs_check -v /dev/hda5 and xfs_check -v -i /dev/hda5)? > > > Hello Lachlan, > > thanks for the hints. So far it didn't occur again (at least not that I am > aware of) - well I don't expect it to happen often and am not really sure > whether it will happen again at all. > > >>Thanks for reporting this problem. > > > You are welcome. Without further info reporting it to the bugtracker > doesn't make much sense to me. I will keep an eye on it. If it happens > again, I will try the hints you gave me. I run xfs_check anyway and thus > can easily give it a "-v >xfs_check.txt". I thought I would have to use > xfs_db stuff to get further info. Now that you mention it, printing out the inode in xfs_db might be useful. > > Regards, From owner-xfs@oss.sgi.com Mon Dec 11 22:37:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 22:37:43 -0800 (PST) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.25]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBC6bTqw026954 for ; Mon, 11 Dec 2006 22:37:30 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id kBC6aVID001120 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 11 Dec 2006 22:36:32 -0800 Received: from box (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id kBC6aUow023846; Mon, 11 Dec 2006 22:36:30 -0800 Date: Mon, 11 Dec 2006 22:36:30 -0800 From: Andrew Morton To: Dmitriy Monakhov Cc: Dmitriy Monakhov , linux-kernel@vger.kernel.org, Linux Memory Management , , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect error handling inside generic_file_direct_write Message-Id: <20061211223630.a96ef156.akpm@osdl.org> In-Reply-To: <87lkld31vd.fsf@sw.ru> References: <87k60y1rq4.fsf@sw.ru> <20061211124052.144e69a0.akpm@osdl.org> <87lkld31vd.fsf@sw.ru> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.162 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9967 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: xfs Content-Length: 1907 Lines: 57 On Tue, 12 Dec 2006 12:22:14 +0300 Dmitriy Monakhov wrote: > >> @@ -2041,6 +2041,14 @@ generic_file_direct_write(struct kiocb * > >> mark_inode_dirty(inode); > >> } > >> *ppos = end; > >> + } else if (written < 0) { > >> + loff_t isize = i_size_read(inode); > >> + /* > >> + * generic_file_direct_IO() may have instantiated a few blocks > >> + * outside i_size. Trim these off again. > >> + */ > >> + if (pos + count > isize) > >> + vmtruncate(inode, isize); > >> } > >> > > > > XFS (at least) can call generic_file_direct_write() with i_mutex not held. > How could it be ? > > from mm/filemap.c:2046 generic_file_direct_write() comment right after > place where i want to add vmtruncate() > /* > * Sync the fs metadata but not the minor inode changes and > * of course not the data as we did direct DMA for the IO. > * i_mutex is held, which protects generic_osync_inode() from > * livelocking. > */ > > > And vmtruncate() expects i_mutex to be held. > generic_file_direct_IO must called under i_mutex too > from mm/filemap.c:2388 > /* > * Called under i_mutex for writes to S_ISREG files. Returns -EIO if something > * went wrong during pagecache shootdown. > */ > static ssize_t > generic_file_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov, yup, the comments are wrong. > This means XFS generic_file_direct_write() call generic_file_direct_IO() without > i_mutex held too? Think so. XFS uses blockdev_direct_IO_own_locking(). We'd need to check with the XFS guys regarding its precise operation and what needs to be done here. > > > > I guess a suitable solution would be to push this problem back up to the > > callers: let them decide whether to run vmtruncate() and if so, to ensure > > that i_mutex is held. > > > > The existence of generic_file_aio_write_nolock() makes that rather messy > > though. From owner-xfs@oss.sgi.com Mon Dec 11 23:03:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 11 Dec 2006 23:04:04 -0800 (PST) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBC73iqw030368 for ; Mon, 11 Dec 2006 23:03:46 -0800 Received: from localhost ([192.168.0.78]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id kBC6M6wm019681; Tue, 12 Dec 2006 09:22:07 +0300 (MSK) To: Andrew Morton Cc: Dmitriy Monakhov , linux-kernel@vger.kernel.org, Linux Memory Management , , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect error handling inside generic_file_direct_write References: <87k60y1rq4.fsf@sw.ru> <20061211124052.144e69a0.akpm@osdl.org> From: Dmitriy Monakhov Date: Tue, 12 Dec 2006 12:22:14 +0300 In-Reply-To: <20061211124052.144e69a0.akpm@osdl.org> (Andrew Morton's message of "Mon, 11 Dec 2006 12:40:52 -0800") Message-ID: <87lkld31vd.fsf@sw.ru> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 9968 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dmonakhov@sw.ru Precedence: bulk X-list: xfs Content-Length: 3143 Lines: 84 Andrew Morton writes: > On Mon, 11 Dec 2006 16:34:27 +0300 > Dmitriy Monakhov wrote: > >> OpenVZ team has discovered error inside generic_file_direct_write() >> If generic_file_direct_IO() has fail (ENOSPC condition) it may have instantiated >> a few blocks outside i_size. And fsck will complain about wrong i_size >> (ext2, ext3 and reiserfs interpret i_size and biggest block difference as error), >> after fsck will fix error i_size will be increased to the biggest block, >> but this blocks contain gurbage from previous write attempt, this is not >> information leak, but its silence file data corruption. >> We need truncate any block beyond i_size after write have failed , do in simular >> generic_file_buffered_write() error path. >> >> Exampe: >> open("mnt2/FILE3", O_WRONLY|O_CREAT|O_DIRECT, 0666) = 3 >> write(3, "aaaaaa"..., 4096) = -1 ENOSPC (No space left on device) >> >> stat mnt2/FILE3 >> File: `mnt2/FILE3' >> Size: 0 Blocks: 4 IO Block: 4096 regular empty file >> >>>>>>>>>>>>>>>>>>>>>>^^^^^^^^^^ file size is less than biggest block idx >> Device: 700h/1792d Inode: 14 Links: 1 >> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) >> >> fsck.ext2 -f -n mnt1/fs_img >> Pass 1: Checking inodes, blocks, and sizes >> Inode 14, i_size is 0, should be 2048. Fix? no >> >> Signed-off-by: Dmitriy Monakhov >> ---------- >> >> diff --git a/mm/filemap.c b/mm/filemap.c >> index 7b84dc8..bf7cf6c 100644 >> --- a/mm/filemap.c >> +++ b/mm/filemap.c >> @@ -2041,6 +2041,14 @@ generic_file_direct_write(struct kiocb * >> mark_inode_dirty(inode); >> } >> *ppos = end; >> + } else if (written < 0) { >> + loff_t isize = i_size_read(inode); >> + /* >> + * generic_file_direct_IO() may have instantiated a few blocks >> + * outside i_size. Trim these off again. >> + */ >> + if (pos + count > isize) >> + vmtruncate(inode, isize); >> } >> > > XFS (at least) can call generic_file_direct_write() with i_mutex not held. How could it be ? from mm/filemap.c:2046 generic_file_direct_write() comment right after place where i want to add vmtruncate() /* * Sync the fs metadata but not the minor inode changes and * of course not the data as we did direct DMA for the IO. * i_mutex is held, which protects generic_osync_inode() from * livelocking. */ > And vmtruncate() expects i_mutex to be held. generic_file_direct_IO must called under i_mutex too from mm/filemap.c:2388 /* * Called under i_mutex for writes to S_ISREG files. Returns -EIO if something * went wrong during pagecache shootdown. */ static ssize_t generic_file_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov, This means XFS generic_file_direct_write() call generic_file_direct_IO() without i_mutex held too? > > I guess a suitable solution would be to push this problem back up to the > callers: let them decide whether to run vmtruncate() and if so, to ensure > that i_mutex is held. > > The existence of generic_file_aio_write_nolock() makes that rather messy > though. From owner-xfs@oss.sgi.com Tue Dec 12 01:21:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 01:22:06 -0800 (PST) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBC9Lmqw018593 for ; Tue, 12 Dec 2006 01:21:50 -0800 Received: from localhost ([192.168.0.78]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id kBC9KhPv007625; Tue, 12 Dec 2006 12:20:45 +0300 (MSK) To: Andrew Morton Cc: Dmitriy Monakhov , linux-kernel@vger.kernel.org, Linux Memory Management , , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect error handling inside generic_file_direct_write References: <87k60y1rq4.fsf@sw.ru> <20061211124052.144e69a0.akpm@osdl.org> From: Dmitriy Monakhov Date: Tue, 12 Dec 2006 15:20:52 +0300 In-Reply-To: <20061211124052.144e69a0.akpm@osdl.org> (Andrew Morton's message of "Mon, 11 Dec 2006 12:40:52 -0800") Message-ID: <87bqm9tie3.fsf@sw.ru> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 9969 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dmonakhov@sw.ru Precedence: bulk X-list: xfs Content-Length: 2808 Lines: 72 Andrew Morton writes: > On Mon, 11 Dec 2006 16:34:27 +0300 > Dmitriy Monakhov wrote: > >> OpenVZ team has discovered error inside generic_file_direct_write() >> If generic_file_direct_IO() has fail (ENOSPC condition) it may have instantiated >> a few blocks outside i_size. And fsck will complain about wrong i_size >> (ext2, ext3 and reiserfs interpret i_size and biggest block difference as error), >> after fsck will fix error i_size will be increased to the biggest block, >> but this blocks contain gurbage from previous write attempt, this is not >> information leak, but its silence file data corruption. >> We need truncate any block beyond i_size after write have failed , do in simular >> generic_file_buffered_write() error path. >> >> Exampe: >> open("mnt2/FILE3", O_WRONLY|O_CREAT|O_DIRECT, 0666) = 3 >> write(3, "aaaaaa"..., 4096) = -1 ENOSPC (No space left on device) >> >> stat mnt2/FILE3 >> File: `mnt2/FILE3' >> Size: 0 Blocks: 4 IO Block: 4096 regular empty file >> >>>>>>>>>>>>>>>>>>>>>>^^^^^^^^^^ file size is less than biggest block idx >> Device: 700h/1792d Inode: 14 Links: 1 >> Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) >> >> fsck.ext2 -f -n mnt1/fs_img >> Pass 1: Checking inodes, blocks, and sizes >> Inode 14, i_size is 0, should be 2048. Fix? no >> >> Signed-off-by: Dmitriy Monakhov >> ---------- >> >> diff --git a/mm/filemap.c b/mm/filemap.c >> index 7b84dc8..bf7cf6c 100644 >> --- a/mm/filemap.c >> +++ b/mm/filemap.c >> @@ -2041,6 +2041,14 @@ generic_file_direct_write(struct kiocb * >> mark_inode_dirty(inode); >> } >> *ppos = end; >> + } else if (written < 0) { >> + loff_t isize = i_size_read(inode); >> + /* >> + * generic_file_direct_IO() may have instantiated a few blocks >> + * outside i_size. Trim these off again. >> + */ >> + if (pos + count > isize) >> + vmtruncate(inode, isize); >> } >> > > XFS (at least) can call generic_file_direct_write() with i_mutex not held. > And vmtruncate() expects i_mutex to be held. > > I guess a suitable solution would be to push this problem back up to the > callers: let them decide whether to run vmtruncate() and if so, to ensure > that i_mutex is held. > > The existence of generic_file_aio_write_nolock() makes that rather messy > though. This means we may call generic_file_aio_write_nolock() without i_mutex, right? but call trace is : generic_file_aio_write_nolock() ->generic_file_buffered_write() /* i_mutex not held here */ but according to filemaps locking rules: mm/filemap.c:77 .. * ->i_mutex (generic_file_buffered_write) * ->mmap_sem (fault_in_pages_readable->do_page_fault) .. I'm confused a litle bit, where is the truth? From owner-xfs@oss.sgi.com Tue Dec 12 01:26:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 01:26:53 -0800 (PST) Received: from mail.lichtvoll.de (13.unused.teamix.net [194.150.191.13] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBC9Qaqw019255 for ; Tue, 12 Dec 2006 01:26:38 -0800 Received: from localhost (dslb-084-056-087-075.pools.arcor-ip.net [84.56.87.75]) by mail.lichtvoll.de (Postfix) with ESMTP id DCE285AD2E; Tue, 12 Dec 2006 10:25:45 +0100 (CET) From: Martin Steigerwald To: linux-xfs@oss.sgi.com, lachlan@sgi.com Subject: hints on how to help debugging as FAQ entry (Re: invalid directory entry - bad magic number on inode) Date: Tue, 12 Dec 2006 10:25:41 +0100 User-Agent: KMail/1.9.5 Cc: xfs-dev@sgi.com References: <200612082100.00395.Martin@lichtvoll.de> <200612112111.08209.Martin@lichtvoll.de> <457DFA6A.9050200@sgi.com> In-Reply-To: <457DFA6A.9050200@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612121025.42895.Martin@lichtvoll.de> X-archive-position: 9970 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Content-Length: 2012 Lines: 52 Am Dienstag 12 Dezember 2006 01:40 schrieb Lachlan McIlroy: > > You are welcome. Without further info reporting it to the bugtracker > > doesn't make much sense to me. I will keep an eye on it. If it > > happens again, I will try the hints you gave me. I run xfs_check > > anyway and thus can easily give it a "-v >xfs_check.txt". I thought I > > would have to use xfs_db stuff to get further info. > > Now that you mention it, printing out the inode in xfs_db might be > useful. Hello Lachlan, well I can do that too... my problem is just: As I use the notebook for daily work I have to fix it up quickly when problems arise. So usually I can not afford to report first and await instructions on what to do. I also currently often have no storage space left to store the complete partition onto. So ideally I have some hints on how to help debugging before an incident happens. I think this would make a nice FAQ entry, too. It could contain: 1) xfs_check -v 2) xfs_check -v -i 3) xfs_db stuff 4) probably some hints to determine a useful range for dd / ddrescue from xfs_check output so that people with either very large partitions or low storage space can just copy a part of the defect partition for inspection. Well if thats useful. A complete partition would still be better cause it is possible to use the XFS tools on it 5) probably some hints on how to store a partition in a file with compression... somewhere along the lines of piping dd into bzip2 and bzip2 into a file. maybe "cat /dev/hda1 | bzip2 >mypartition" What do you think? Those hints could help XFS developers to get useful bug reports... I am willing to collect the hints and writing a FAQ entry about it that you can include in your FAQ. Well that would probably basically be an extension to: " Q: What information should I include when reporting a problem?" Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Dec 12 01:53:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 01:53:43 -0800 (PST) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.25]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBC9rVqw023049 for ; Tue, 12 Dec 2006 01:53:33 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id kBC9qXID011297 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Dec 2006 01:52:33 -0800 Received: from box (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id kBC9qWft028769; Tue, 12 Dec 2006 01:52:32 -0800 Date: Tue, 12 Dec 2006 01:52:32 -0800 From: Andrew Morton To: Dmitriy Monakhov Cc: Dmitriy Monakhov , linux-kernel@vger.kernel.org, Linux Memory Management , , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect error handling inside generic_file_direct_write Message-Id: <20061212015232.eacfbb46.akpm@osdl.org> In-Reply-To: <87bqm9tie3.fsf@sw.ru> References: <87k60y1rq4.fsf@sw.ru> <20061211124052.144e69a0.akpm@osdl.org> <87bqm9tie3.fsf@sw.ru> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.162 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9971 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: xfs Content-Length: 1011 Lines: 26 On Tue, 12 Dec 2006 15:20:52 +0300 Dmitriy Monakhov wrote: > > XFS (at least) can call generic_file_direct_write() with i_mutex not held. > > And vmtruncate() expects i_mutex to be held. > > > > I guess a suitable solution would be to push this problem back up to the > > callers: let them decide whether to run vmtruncate() and if so, to ensure > > that i_mutex is held. > > > > The existence of generic_file_aio_write_nolock() makes that rather messy > > though. > This means we may call generic_file_aio_write_nolock() without i_mutex, right? > but call trace is : > generic_file_aio_write_nolock() > ->generic_file_buffered_write() /* i_mutex not held here */ > but according to filemaps locking rules: mm/filemap.c:77 > .. > * ->i_mutex (generic_file_buffered_write) > * ->mmap_sem (fault_in_pages_readable->do_page_fault) > .. > I'm confused a litle bit, where is the truth? xfs_write() calls generic_file_direct_write() without taking i_mutex for O_DIRECT writes. From owner-xfs@oss.sgi.com Tue Dec 12 02:19:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 02:19:53 -0800 (PST) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBCAJZqw026594 for ; Tue, 12 Dec 2006 02:19:38 -0800 Received: from localhost ([192.168.0.78]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id kBCAIO8L022147; Tue, 12 Dec 2006 13:18:25 +0300 (MSK) To: Andrew Morton Cc: Dmitriy Monakhov , Dmitriy Monakhov , linux-kernel@vger.kernel.org, Linux Memory Management , , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect error handling inside generic_file_direct_write References: <87k60y1rq4.fsf@sw.ru> <20061211124052.144e69a0.akpm@osdl.org> <87bqm9tie3.fsf@sw.ru> <20061212015232.eacfbb46.akpm@osdl.org> From: Dmitriy Monakhov Date: Tue, 12 Dec 2006 16:18:32 +0300 In-Reply-To: <20061212015232.eacfbb46.akpm@osdl.org> (Andrew Morton's message of "Tue, 12 Dec 2006 01:52:32 -0800") Message-ID: <87psapz1zr.fsf@sw.ru> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-archive-position: 9972 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dmonakhov@sw.ru Precedence: bulk X-list: xfs Content-Length: 2122 Lines: 63 --=-=-= Andrew Morton writes: > On Tue, 12 Dec 2006 15:20:52 +0300 > Dmitriy Monakhov wrote: > >> > XFS (at least) can call generic_file_direct_write() with i_mutex not held. >> > And vmtruncate() expects i_mutex to be held. >> > >> > I guess a suitable solution would be to push this problem back up to the >> > callers: let them decide whether to run vmtruncate() and if so, to ensure >> > that i_mutex is held. >> > >> > The existence of generic_file_aio_write_nolock() makes that rather messy >> > though. >> This means we may call generic_file_aio_write_nolock() without i_mutex, right? >> but call trace is : >> generic_file_aio_write_nolock() >> ->generic_file_buffered_write() /* i_mutex not held here */ >> but according to filemaps locking rules: mm/filemap.c:77 >> .. >> * ->i_mutex (generic_file_buffered_write) >> * ->mmap_sem (fault_in_pages_readable->do_page_fault) >> .. >> I'm confused a litle bit, where is the truth? > > xfs_write() calls generic_file_direct_write() without taking i_mutex for > O_DIRECT writes. Yes, but my quastion is about __generic_file_aio_write_nolock(). As i understand _nolock sufix means that i_mutex was already locked by caller, am i right ? If yes, than __generic_file_aio_write_nolock() is beter place for vmtrancate() acclivity after generic_file_direct_write() has fail. Signed-off-by: Dmitriy Monakhov ------- --=-=-= Content-Disposition: inline; filename=diff-generic-direct-io-write-fix diff --git a/mm/filemap.c b/mm/filemap.c index 7b84dc8..723d2ca 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2282,6 +2282,15 @@ __generic_file_aio_write_nolock(struct k written = generic_file_direct_write(iocb, iov, &nr_segs, pos, ppos, count, ocount); + if (written < 0) { + loff_t isize = i_size_read(inode); + /* + * generic_file_direct_write() may have instantiated + * a few blocks outside i_size. Trim these off again. + */ + if (pos + count > isize) + vmtruncate(inode, isize); + } if (written < 0 || written == count) goto out; /* --=-=-=-- From owner-xfs@oss.sgi.com Tue Dec 12 02:41:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 02:41:43 -0800 (PST) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.25]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBCAfVqw029406 for ; Tue, 12 Dec 2006 02:41:33 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id kBCAeSID014053 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Dec 2006 02:40:30 -0800 Received: from box (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id kBCAeRRK029838; Tue, 12 Dec 2006 02:40:27 -0800 Date: Tue, 12 Dec 2006 02:40:27 -0800 From: Andrew Morton To: Dmitriy Monakhov Cc: Dmitriy Monakhov , linux-kernel@vger.kernel.org, Linux Memory Management , , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect error handling inside generic_file_direct_write Message-Id: <20061212024027.6c2a79d3.akpm@osdl.org> In-Reply-To: <87psapz1zr.fsf@sw.ru> References: <87k60y1rq4.fsf@sw.ru> <20061211124052.144e69a0.akpm@osdl.org> <87bqm9tie3.fsf@sw.ru> <20061212015232.eacfbb46.akpm@osdl.org> <87psapz1zr.fsf@sw.ru> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.162 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 9973 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@osdl.org Precedence: bulk X-list: xfs Content-Length: 1291 Lines: 30 On Tue, 12 Dec 2006 16:18:32 +0300 Dmitriy Monakhov wrote: > >> but according to filemaps locking rules: mm/filemap.c:77 > >> .. > >> * ->i_mutex (generic_file_buffered_write) > >> * ->mmap_sem (fault_in_pages_readable->do_page_fault) > >> .. > >> I'm confused a litle bit, where is the truth? > > > > xfs_write() calls generic_file_direct_write() without taking i_mutex for > > O_DIRECT writes. > Yes, but my quastion is about __generic_file_aio_write_nolock(). > As i understand _nolock sufix means that i_mutex was already locked > by caller, am i right ? Nope. It just means that __generic_file_aio_write_nolock() doesn't take the lock. We don't assume or require that the caller took it. For example the raw driver calls generic_file_aio_write_nolock() without taking i_mutex. Raw isn't relevant to the problem (although ocfs2 might be). But we cannot assume that all callers have taken i_mutex, I think. I guess we can make that a rule (document it, add BUG_ON(!mutex_is_locked(..)) if it isn't a blockdev) if needs be. After really checking that this matches reality for all callers. It's important, too - if we have an unprotected i_size_write() then the seqlock can get out of sync due to a race and then i_size_read() locks up the kernel. From owner-xfs@oss.sgi.com Tue Dec 12 07:02:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 07:02:13 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBCF20qw001732 for ; Tue, 12 Dec 2006 07:02:02 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id EC78A616D16C; Tue, 12 Dec 2006 09:32:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id E694116191684; Tue, 12 Dec 2006 09:32:38 -0500 (EST) Date: Tue, 12 Dec 2006 09:32:38 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: =?iso-8859-2?Q?Haar_J=E1nos?= cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: xfslogd-spinlock bug? In-Reply-To: <003701c71d78$33ed28d0$0400a8c0@dcccs> Message-ID: References: <003701c71d78$33ed28d0$0400a8c0@dcccs> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1463747160-1853555891-1165933958=:19050" X-archive-position: 9974 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 5997 Lines: 148 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1463747160-1853555891-1165933958=:19050 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE I'm not sure what is causing this problem but I was curious is this on a=20 32bit or 64bit platform? Justin. On Tue, 12 Dec 2006, Haar J=C3=A1nos wrote: > Hello, list, >=20 > I am the "big red button men" with the one big 14TB xfs, if somebody can > remember me. :-) >=20 > Now i found something in the 2.6.16.18, and try the 2.6.18.4, and the > 2.6.19, but the bug still exists: >=20 > Dec 11 22:47:21 dy-base BUG: spinlock bad magic on CPU#3, xfslogd/3/317 > Dec 11 22:47:21 dy-base general protection fault: 0000 [1] > Dec 11 22:47:21 dy-base SMP > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base CPU 3 > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base Modules linked in: > Dec 11 22:47:21 dy-base nbd > Dec 11 22:47:21 dy-base rd > Dec 11 22:47:21 dy-base netconsole > Dec 11 22:47:21 dy-base e1000 > Dec 11 22:47:21 dy-base video > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base Pid: 317, comm: xfslogd/3 Not tainted 2.6.19 #1 > Dec 11 22:47:21 dy-base RIP: 0010:[] > Dec 11 22:47:21 dy-base [] spin_bug+0x69/0xdf > Dec 11 22:47:21 dy-base RSP: 0018:ffff81011fb89bc0 EFLAGS: 00010002 > Dec 11 22:47:21 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: > 0000000000000000 > Dec 11 22:47:21 dy-base RDX: ffffffff808137a0 RSI: 0000000000000082 RDI: > 0000000100000000 > Dec 11 22:47:21 dy-base RBP: ffff81011fb89be0 R08: 0000000000026a70 R09: > 000000006b6b6b6b > Dec 11 22:47:21 dy-base R10: 0000000000000082 R11: ffff81000584d380 R12: > ffff8100db92ad80 > Dec 11 22:47:21 dy-base R13: ffffffff80642dc6 R14: 0000000000000000 R15: > 0000000000000003 > Dec 11 22:47:21 dy-base FS: 0000000000000000(0000) > GS:ffff81011fc76b90(0000) knlGS:0000000000000000 > Dec 11 22:47:21 dy-base CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b > Dec 11 22:47:21 dy-base CR2: 00002ba007700000 CR3: 0000000108c05000 CR4: > 00000000000006e0 > Dec 11 22:47:21 dy-base Process xfslogd/3 (pid: 317, threadinfo > ffff81011fb88000, task ffff81011fa7f830) > Dec 11 22:47:21 dy-base Stack: > Dec 11 22:47:21 dy-base ffff81011fb89be0 > Dec 11 22:47:21 dy-base ffff8100db92ad80 > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base ffff81011fb89c10 > Dec 11 22:47:21 dy-base ffffffff803f3bdc > Dec 11 22:47:21 dy-base 0000000000000282 > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base ffff81011fb89c30 > Dec 11 22:47:21 dy-base ffffffff805e7f2b > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base Call Trace: > Dec 11 22:47:21 dy-base [] _raw_spin_lock+0x23/0xf1 > Dec 11 22:47:21 dy-base [] _spin_lock_irqsave+0x11/0x18 > Dec 11 22:47:21 dy-base [] __wake_up+0x22/0x50 > Dec 11 22:47:21 dy-base [] xfs_buf_unpin+0x21/0x23 > Dec 11 22:47:21 dy-base [] xfs_buf_item_unpin+0x2e/0xa6 > Dec 11 22:47:21 dy-base [] > xfs_trans_chunk_committed+0xc3/0xf7 > Dec 11 22:47:21 dy-base [] xfs_trans_committed+0x49/0x= de > Dec 11 22:47:21 dy-base [] > xlog_state_do_callback+0x185/0x33f > Dec 11 22:47:21 dy-base [] xlog_iodone+0x104/0x131 > Dec 11 22:47:22 dy-base [] xfs_buf_iodone_work+0x1a/0x= 3e > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > Dec 11 22:47:22 dy-base [] run_workqueue+0xa8/0xf8 > Dec 11 22:47:22 dy-base [] xfs_buf_iodone_work+0x0/0x3e > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > Dec 11 22:47:22 dy-base [] worker_thread+0xfb/0x134 > Dec 11 22:47:22 dy-base [] default_wake_function+0x0/0= xf > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > Dec 11 22:47:22 dy-base [] kthread+0xd8/0x10b > Dec 11 22:47:22 dy-base [] schedule_tail+0x45/0xa6 > Dec 11 22:47:22 dy-base [] child_rip+0xa/0x12 > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > Dec 11 22:47:22 dy-base [] kthread+0x0/0x10b > Dec 11 22:47:22 dy-base [] child_rip+0x0/0x12 > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base Code: > Dec 11 22:47:22 dy-base 8b > Dec 11 22:47:22 dy-base 83 > Dec 11 22:47:22 dy-base 0c > Dec 11 22:47:22 dy-base 01 > Dec 11 22:47:22 dy-base 00 > Dec 11 22:47:22 dy-base 00 > Dec 11 22:47:22 dy-base 48 > Dec 11 22:47:22 dy-base 8d > Dec 11 22:47:22 dy-base 8b > Dec 11 22:47:22 dy-base 98 > Dec 11 22:47:22 dy-base 02 > Dec 11 22:47:22 dy-base 00 > Dec 11 22:47:22 dy-base 00 > Dec 11 22:47:22 dy-base 41 > Dec 11 22:47:22 dy-base 8b > Dec 11 22:47:22 dy-base 54 > Dec 11 22:47:22 dy-base 24 > Dec 11 22:47:22 dy-base 04 > Dec 11 22:47:22 dy-base 41 > Dec 11 22:47:22 dy-base 89 > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base RIP > Dec 11 22:47:22 dy-base [] spin_bug+0x69/0xdf > Dec 11 22:47:22 dy-base RSP > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base Kernel panic - not syncing: Fatal exception > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base Rebooting in 5 seconds.. >=20 > After this, sometimes the server reboots normally, but sometimes hangs, no > console, no sysreq, no nothing. >=20 > This is a "simple" crash, no "too much" data lost, or else. >=20 > Can somebody help me to tracking down the problem? >=20 > Thanks, > Janos Haar >=20 >=20 >=20 >=20 ---1463747160-1853555891-1165933958=:19050-- From owner-xfs@oss.sgi.com Tue Dec 12 12:15:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 12:15:30 -0800 (PST) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBCKFJqw012477 for ; Tue, 12 Dec 2006 12:15:21 -0800 Received: from localhost ([192.168.0.78]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id kBCKE9M9003621; Tue, 12 Dec 2006 23:14:11 +0300 (MSK) To: Andrew Morton Cc: Dmitriy Monakhov , linux-kernel@vger.kernel.org, Linux Memory Management , , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect error handling inside generic_file_direct_write References: <87k60y1rq4.fsf@sw.ru> <20061211124052.144e69a0.akpm@osdl.org> <87bqm9tie3.fsf@sw.ru> <20061212015232.eacfbb46.akpm@osdl.org> <87psapz1zr.fsf@sw.ru> <20061212024027.6c2a79d3.akpm@osdl.org> From: Dmitriy Monakhov Date: Wed, 13 Dec 2006 02:14:18 +0300 In-Reply-To: <20061212024027.6c2a79d3.akpm@osdl.org> (Andrew Morton's message of "Tue, 12 Dec 2006 02:40:27 -0800") Message-ID: <87y7pcn1v9.fsf@sw.ru> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-archive-position: 9975 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dmonakhov@openvz.org Precedence: bulk X-list: xfs Content-Length: 3747 Lines: 103 --=-=-= Andrew Morton writes: > On Tue, 12 Dec 2006 16:18:32 +0300 > Dmitriy Monakhov wrote: > >> >> but according to filemaps locking rules: mm/filemap.c:77 >> >> .. >> >> * ->i_mutex (generic_file_buffered_write) >> >> * ->mmap_sem (fault_in_pages_readable->do_page_fault) >> >> .. >> >> I'm confused a litle bit, where is the truth? >> > >> > xfs_write() calls generic_file_direct_write() without taking i_mutex for >> > O_DIRECT writes. >> Yes, but my quastion is about __generic_file_aio_write_nolock(). >> As i understand _nolock sufix means that i_mutex was already locked >> by caller, am i right ? > > Nope. It just means that __generic_file_aio_write_nolock() doesn't take > the lock. We don't assume or require that the caller took it. For example > the raw driver calls generic_file_aio_write_nolock() without taking > i_mutex. Raw isn't relevant to the problem (although ocfs2 might be). But > we cannot assume that all callers have taken i_mutex, I think. > > I guess we can make that a rule (document it, add > BUG_ON(!mutex_is_locked(..)) if it isn't a blockdev) if needs be. After > really checking that this matches reality for all callers. I've checked generic_file_aio_write_nolock() callers for non blockdev. Only ocfs2 call it explicitly, and do it under i_mutex. So we need to do: 1) Change wrong comments. 2) Add BUG_ON(!mutex_is_locked(..)) for non blkdev. 3) Invoke vmtruncate only for non blkdev. Signed-off-by: Dmitriy Monakhov ------- --=-=-= Content-Disposition: inline; filename=direct-io-fix.patch diff --git a/mm/filemap.c b/mm/filemap.c index 7b84dc8..540ef5e 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2046,8 +2046,8 @@ generic_file_direct_write(struct kiocb * /* * Sync the fs metadata but not the minor inode changes and * of course not the data as we did direct DMA for the IO. - * i_mutex is held, which protects generic_osync_inode() from - * livelocking. + * i_mutex may not being held, if so some specific locking + * ordering must protect generic_osync_inode() from livelocking. */ if (written >= 0 && ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { int err = generic_osync_inode(inode, mapping, OSYNC_METADATA); @@ -2282,6 +2282,17 @@ __generic_file_aio_write_nolock(struct k written = generic_file_direct_write(iocb, iov, &nr_segs, pos, ppos, count, ocount); + /* + * If host is not S_ISBLK generic_file_direct_write() may + * have instantiated a few blocks outside i_size files + * Trim these off again. + */ + if (unlikely(written < 0) && !S_ISBLK(inode->i_mode)) { + loff_t isize = i_size_read(inode); + if (pos + count > isize) + vmtruncate(inode, isize); + } + if (written < 0 || written == count) goto out; /* @@ -2344,6 +2355,13 @@ ssize_t generic_file_aio_write_nolock(st ssize_t ret; BUG_ON(iocb->ki_pos != pos); + /* + * generic_file_buffered_write() may be called inside + * __generic_file_aio_write_nolock() even in case of + * O_DIRECT for non S_ISBLK files. So i_mutex must be held. + */ + if (!S_ISBLK(inode->i_mode)) + BUG_ON(!mutex_is_locked(&inode->i_mutex)); ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, &iocb->ki_pos); @@ -2386,8 +2404,8 @@ ssize_t generic_file_aio_write(struct ki EXPORT_SYMBOL(generic_file_aio_write); /* - * Called under i_mutex for writes to S_ISREG files. Returns -EIO if something - * went wrong during pagecache shootdown. + * May be called without i_mutex for writes to S_ISREG files. + * Returns -EIO if something went wrong during pagecache shootdown. */ static ssize_t generic_file_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov, --=-=-=-- From owner-xfs@oss.sgi.com Tue Dec 12 17:13:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 17:13:21 -0800 (PST) Received: from netcenter.hu (ns.netcenter.hu [195.228.254.57]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBD1DAqw017333 for ; Tue, 12 Dec 2006 17:13:11 -0800 Received: from dcccs (dsl5401D062.pool.t-online.hu [84.1.208.98]) by netcenter.hu (8.13.4/8.12.8) with SMTP id kBD19SIt023118; Wed, 13 Dec 2006 02:09:32 +0100 Message-ID: <00ab01c71e53$942af2f0$0400a8c0@dcccs> From: =?utf-8?Q?Haar_J=C3=A1nos?= To: "Justin Piszcz" Cc: , References: <003701c71d78$33ed28d0$0400a8c0@dcccs> Subject: Re: xfslogd-spinlock bug? Date: Wed, 13 Dec 2006 02:11:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-archive-position: 9977 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 7006 Lines: 183 Hello, Justin, This is a 64bit system. But i cannot understand, what is the curious? :-) I am not a kernel developer, and not a C programmer, but the long pointers shows me, the 64 bit. Or am i on the wrong clue? :-) Anyway, this issue happens for me about daily, or max 2-3 day often. But i have no idea what cause this exactly. The 2.6.16.18 was stable for me a long time, and one day starts to tricking me, and happens more and more often. Thats why i thinking some bad part of the (14TB) FS on the disks. (this fs have a lot of errors, what the xfs_repair cannot be corrected, but anyway this is a productive system, and works well, except this issue. Some months before i have replaced the parity disk in one of the RAID4 array, and the next day, during the resync process, another one disk died. I almost lost everything, but thanks to the raid4, and mdadm, i have successfully recovered a lot of data with the 1 day older parity-only drive. This was really bad, and leave some scars on the fs. ) This issue looks like for me a race condition between the cpus. (2x Xeon HT) Am i right? :-) Thanks, Janos ----- Original Message ----- From: "Justin Piszcz" To: "Haar János" Cc: ; Sent: Tuesday, December 12, 2006 3:32 PM Subject: Re: xfslogd-spinlock bug? I'm not sure what is causing this problem but I was curious is this on a 32bit or 64bit platform? Justin. On Tue, 12 Dec 2006, Haar János wrote: > Hello, list, > > I am the "big red button men" with the one big 14TB xfs, if somebody can > remember me. :-) > > Now i found something in the 2.6.16.18, and try the 2.6.18.4, and the > 2.6.19, but the bug still exists: > > Dec 11 22:47:21 dy-base BUG: spinlock bad magic on CPU#3, xfslogd/3/317 > Dec 11 22:47:21 dy-base general protection fault: 0000 [1] > Dec 11 22:47:21 dy-base SMP > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base CPU 3 > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base Modules linked in: > Dec 11 22:47:21 dy-base nbd > Dec 11 22:47:21 dy-base rd > Dec 11 22:47:21 dy-base netconsole > Dec 11 22:47:21 dy-base e1000 > Dec 11 22:47:21 dy-base video > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base Pid: 317, comm: xfslogd/3 Not tainted 2.6.19 #1 > Dec 11 22:47:21 dy-base RIP: 0010:[] > Dec 11 22:47:21 dy-base [] spin_bug+0x69/0xdf > Dec 11 22:47:21 dy-base RSP: 0018:ffff81011fb89bc0 EFLAGS: 00010002 > Dec 11 22:47:21 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: > 0000000000000000 > Dec 11 22:47:21 dy-base RDX: ffffffff808137a0 RSI: 0000000000000082 RDI: > 0000000100000000 > Dec 11 22:47:21 dy-base RBP: ffff81011fb89be0 R08: 0000000000026a70 R09: > 000000006b6b6b6b > Dec 11 22:47:21 dy-base R10: 0000000000000082 R11: ffff81000584d380 R12: > ffff8100db92ad80 > Dec 11 22:47:21 dy-base R13: ffffffff80642dc6 R14: 0000000000000000 R15: > 0000000000000003 > Dec 11 22:47:21 dy-base FS: 0000000000000000(0000) > GS:ffff81011fc76b90(0000) knlGS:0000000000000000 > Dec 11 22:47:21 dy-base CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b > Dec 11 22:47:21 dy-base CR2: 00002ba007700000 CR3: 0000000108c05000 CR4: > 00000000000006e0 > Dec 11 22:47:21 dy-base Process xfslogd/3 (pid: 317, threadinfo > ffff81011fb88000, task ffff81011fa7f830) > Dec 11 22:47:21 dy-base Stack: > Dec 11 22:47:21 dy-base ffff81011fb89be0 > Dec 11 22:47:21 dy-base ffff8100db92ad80 > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base ffff81011fb89c10 > Dec 11 22:47:21 dy-base ffffffff803f3bdc > Dec 11 22:47:21 dy-base 0000000000000282 > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base 0000000000000000 > Dec 11 22:47:21 dy-base ffff81011fb89c30 > Dec 11 22:47:21 dy-base ffffffff805e7f2b > Dec 11 22:47:21 dy-base > Dec 11 22:47:21 dy-base Call Trace: > Dec 11 22:47:21 dy-base [] _raw_spin_lock+0x23/0xf1 > Dec 11 22:47:21 dy-base [] _spin_lock_irqsave+0x11/0x18 > Dec 11 22:47:21 dy-base [] __wake_up+0x22/0x50 > Dec 11 22:47:21 dy-base [] xfs_buf_unpin+0x21/0x23 > Dec 11 22:47:21 dy-base [] xfs_buf_item_unpin+0x2e/0xa6 > Dec 11 22:47:21 dy-base [] > xfs_trans_chunk_committed+0xc3/0xf7 > Dec 11 22:47:21 dy-base [] xfs_trans_committed+0x49/0xde > Dec 11 22:47:21 dy-base [] > xlog_state_do_callback+0x185/0x33f > Dec 11 22:47:21 dy-base [] xlog_iodone+0x104/0x131 > Dec 11 22:47:22 dy-base [] xfs_buf_iodone_work+0x1a/0x3e > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > Dec 11 22:47:22 dy-base [] run_workqueue+0xa8/0xf8 > Dec 11 22:47:22 dy-base [] xfs_buf_iodone_work+0x0/0x3e > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > Dec 11 22:47:22 dy-base [] worker_thread+0xfb/0x134 > Dec 11 22:47:22 dy-base [] default_wake_function+0x0/0xf > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > Dec 11 22:47:22 dy-base [] kthread+0xd8/0x10b > Dec 11 22:47:22 dy-base [] schedule_tail+0x45/0xa6 > Dec 11 22:47:22 dy-base [] child_rip+0xa/0x12 > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > Dec 11 22:47:22 dy-base [] kthread+0x0/0x10b > Dec 11 22:47:22 dy-base [] child_rip+0x0/0x12 > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base Code: > Dec 11 22:47:22 dy-base 8b > Dec 11 22:47:22 dy-base 83 > Dec 11 22:47:22 dy-base 0c > Dec 11 22:47:22 dy-base 01 > Dec 11 22:47:22 dy-base 00 > Dec 11 22:47:22 dy-base 00 > Dec 11 22:47:22 dy-base 48 > Dec 11 22:47:22 dy-base 8d > Dec 11 22:47:22 dy-base 8b > Dec 11 22:47:22 dy-base 98 > Dec 11 22:47:22 dy-base 02 > Dec 11 22:47:22 dy-base 00 > Dec 11 22:47:22 dy-base 00 > Dec 11 22:47:22 dy-base 41 > Dec 11 22:47:22 dy-base 8b > Dec 11 22:47:22 dy-base 54 > Dec 11 22:47:22 dy-base 24 > Dec 11 22:47:22 dy-base 04 > Dec 11 22:47:22 dy-base 41 > Dec 11 22:47:22 dy-base 89 > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base RIP > Dec 11 22:47:22 dy-base [] spin_bug+0x69/0xdf > Dec 11 22:47:22 dy-base RSP > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base Kernel panic - not syncing: Fatal exception > Dec 11 22:47:22 dy-base > Dec 11 22:47:22 dy-base Rebooting in 5 seconds.. > > After this, sometimes the server reboots normally, but sometimes hangs, no > console, no sysreq, no nothing. > > This is a "simple" crash, no "too much" data lost, or else. > > Can somebody help me to tracking down the problem? > > Thanks, > Janos Haar > > > > From owner-xfs@oss.sgi.com Tue Dec 12 19:13:40 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 19:13:49 -0800 (PST) Received: from mga01.intel.com ([192.55.52.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBD3Ddqw030452 for ; Tue, 12 Dec 2006 19:13:40 -0800 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 12 Dec 2006 18:43:39 -0800 Received: from kwchen-mobl1.amr.corp.intel.com (HELO kwchenmobl1) ([10.3.52.228]) by fmsmga001.fm.intel.com with ESMTP; 12 Dec 2006 18:43:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,160,1165219200"; d="scan'208"; a="176684097:sNHT907581822" From: "Chen, Kenneth W" To: "'Andrew Morton'" , "Dmitriy Monakhov" , "'Christoph Hellwig'" Cc: "Dmitriy Monakhov" , , "Linux Memory Management" , , Subject: RE: [PATCH] incorrect error handling inside generic_file_direct_write Date: Tue, 12 Dec 2006 18:43:37 -0800 Message-ID: <000001c71e60$7df9e010$e434030a@amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Accd2pR8136Co/iERRaWZFk+9jJGrAAgQVRQ In-Reply-To: <20061212024027.6c2a79d3.akpm@osdl.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-archive-position: 9978 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kenneth.w.chen@intel.com Precedence: bulk X-list: xfs Content-Length: 6710 Lines: 174 Andrew Morton wrote on Tuesday, December 12, 2006 2:40 AM > On Tue, 12 Dec 2006 16:18:32 +0300 > Dmitriy Monakhov wrote: > > > >> but according to filemaps locking rules: mm/filemap.c:77 > > >> .. > > >> * ->i_mutex (generic_file_buffered_write) > > >> * ->mmap_sem (fault_in_pages_readable->do_page_fault) > > >> .. > > >> I'm confused a litle bit, where is the truth? > > > > > > xfs_write() calls generic_file_direct_write() without taking i_mutex for > > > O_DIRECT writes. > > Yes, but my quastion is about __generic_file_aio_write_nolock(). > > As i understand _nolock sufix means that i_mutex was already locked > > by caller, am i right ? > > Nope. It just means that __generic_file_aio_write_nolock() doesn't take > the lock. We don't assume or require that the caller took it. For example > the raw driver calls generic_file_aio_write_nolock() without taking > i_mutex. Raw isn't relevant to the problem (although ocfs2 might be). But > we cannot assume that all callers have taken i_mutex, I think. I think we should also clean up generic_file_aio_write_nolock. This was brought up a couple of weeks ago and I gave up too early. Here is my second attempt. How about the following patch, I think we can kill generic_file_aio_write_nolock and merge both *file_aio_write_nolock into one function, then generic_file_aio_write ocfs2_file_aio_write blk_dev->aio_write all points to a non-lock version of __generic_file_aio_write(). First two already hold i_mutex, while the block device's aio_write method doesn't require i_mutex to be held. Signed-off-by: Ken Chen diff -Nurp linux-2.6.19/drivers/char/raw.c linux-2.6.19.ken/drivers/char/raw.c --- linux-2.6.19/drivers/char/raw.c 2006-11-29 13:57:37.000000000 -0800 +++ linux-2.6.19.ken/drivers/char/raw.c 2006-12-12 16:41:39.000000000 -0800 @@ -242,7 +242,7 @@ static const struct file_operations raw_ .read = do_sync_read, .aio_read = generic_file_aio_read, .write = do_sync_write, - .aio_write = generic_file_aio_write_nolock, + .aio_write = __generic_file_aio_write, .open = raw_open, .release= raw_release, .ioctl = raw_ioctl, diff -Nurp linux-2.6.19/fs/block_dev.c linux-2.6.19.ken/fs/block_dev.c --- linux-2.6.19/fs/block_dev.c 2006-11-29 13:57:37.000000000 -0800 +++ linux-2.6.19.ken/fs/block_dev.c 2006-12-12 16:47:58.000000000 -0800 @@ -1198,7 +1198,7 @@ const struct file_operations def_blk_fop .read = do_sync_read, .write = do_sync_write, .aio_read = generic_file_aio_read, - .aio_write = generic_file_aio_write_nolock, + .aio_write = __generic_file_aio_write, .mmap = generic_file_mmap, .fsync = block_fsync, .unlocked_ioctl = block_ioctl, diff -Nurp linux-2.6.19/fs/ocfs2/file.c linux-2.6.19.ken/fs/ocfs2/file.c --- linux-2.6.19/fs/ocfs2/file.c 2006-11-29 13:57:37.000000000 -0800 +++ linux-2.6.19.ken/fs/ocfs2/file.c 2006-12-12 16:42:09.000000000 -0800 @@ -1107,7 +1107,7 @@ static ssize_t ocfs2_file_aio_write(stru /* communicate with ocfs2_dio_end_io */ ocfs2_iocb_set_rw_locked(iocb); - ret = generic_file_aio_write_nolock(iocb, iov, nr_segs, iocb->ki_pos); + ret = __generic_file_aio_write(iocb, iov, nr_segs, iocb->ki_pos); /* buffered aio wouldn't have proper lock coverage today */ BUG_ON(ret == -EIOCBQUEUED && !(filp->f_flags & O_DIRECT)); diff -Nurp linux-2.6.19/include/linux/fs.h linux-2.6.19.ken/include/linux/fs.h --- linux-2.6.19/include/linux/fs.h 2006-11-29 13:57:37.000000000 -0800 +++ linux-2.6.19.ken/include/linux/fs.h 2006-12-12 16:41:58.000000000 -0800 @@ -1742,7 +1742,7 @@ extern int file_send_actor(read_descript int generic_write_checks(struct file *file, loff_t *pos, size_t *count, int isblk); extern ssize_t generic_file_aio_read(struct kiocb *, const struct iovec *, unsigned long, loff_t); extern ssize_t generic_file_aio_write(struct kiocb *, const struct iovec *, unsigned long, loff_t); -extern ssize_t generic_file_aio_write_nolock(struct kiocb *, const struct iovec *, +extern ssize_t __generic_file_aio_write(struct kiocb *, const struct iovec *, unsigned long, loff_t); extern ssize_t generic_file_direct_write(struct kiocb *, const struct iovec *, unsigned long *, loff_t, loff_t *, size_t, size_t); diff -Nurp linux-2.6.19/mm/filemap.c linux-2.6.19.ken/mm/filemap.c --- linux-2.6.19/mm/filemap.c 2006-11-29 13:57:37.000000000 -0800 +++ linux-2.6.19.ken/mm/filemap.c 2006-12-12 16:47:58.000000000 -0800 @@ -2219,9 +2219,9 @@ zero_length_segment: } EXPORT_SYMBOL(generic_file_buffered_write); -static ssize_t -__generic_file_aio_write_nolock(struct kiocb *iocb, const struct iovec *iov, - unsigned long nr_segs, loff_t *ppos) +ssize_t +__generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov, + unsigned long nr_segs, loff_t pos) { struct file *file = iocb->ki_filp; struct address_space * mapping = file->f_mapping; @@ -2229,9 +2229,10 @@ __generic_file_aio_write_nolock(struct k size_t count; /* after file limit checks */ struct inode *inode = mapping->host; unsigned long seg; - loff_t pos; + loff_t *ppos = &iocb->ki_pos; ssize_t written; ssize_t err; + ssize_t ret; ocount = 0; for (seg = 0; seg < nr_segs; seg++) { @@ -2254,7 +2255,6 @@ __generic_file_aio_write_nolock(struct k } count = ocount; - pos = *ppos; vfs_check_frozen(inode->i_sb, SB_FREEZE_WRITE); @@ -2332,32 +2332,16 @@ __generic_file_aio_write_nolock(struct k } out: current->backing_dev_info = NULL; - return written ? written : err; -} - -ssize_t generic_file_aio_write_nolock(struct kiocb *iocb, - const struct iovec *iov, unsigned long nr_segs, loff_t pos) -{ - struct file *file = iocb->ki_filp; - struct address_space *mapping = file->f_mapping; - struct inode *inode = mapping->host; - ssize_t ret; - - BUG_ON(iocb->ki_pos != pos); - - ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, - &iocb->ki_pos); + ret = written ? written : err; if (ret > 0 && ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { - ssize_t err; - err = sync_page_range_nolock(inode, mapping, pos, ret); if (err < 0) ret = err; } return ret; } -EXPORT_SYMBOL(generic_file_aio_write_nolock); +EXPORT_SYMBOL(__generic_file_aio_write); ssize_t generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov, unsigned long nr_segs, loff_t pos) @@ -2370,8 +2354,7 @@ ssize_t generic_file_aio_write(struct ki BUG_ON(iocb->ki_pos != pos); mutex_lock(&inode->i_mutex); - ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, - &iocb->ki_pos); + ret = __generic_file_aio_write(iocb, iov, nr_segs, pos); mutex_unlock(&inode->i_mutex); if (ret > 0 && ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { From owner-xfs@oss.sgi.com Tue Dec 12 22:47:48 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 12 Dec 2006 22:47:54 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBD6ljqw024435 for ; Tue, 12 Dec 2006 22:47:47 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA25351 for ; Wed, 13 Dec 2006 17:46:54 +1100 Message-Id: <200612130646.RAA25351@larry.melbourne.sgi.com> From: "Barry Naujok" To: Subject: xfsprogs 2.8.18 source tarball available on ftp Date: Wed, 13 Dec 2006 17:52:38 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acceg0bb1063srqAQZukeHcXij/FQA== X-archive-position: 9981 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 726 Lines: 19 ftp://oss.sgi.com/projects/xfs/cmd_tars/xfsprogs_2.8.18-1.tar.gz CHANGES since 2.8.16: - Fix "pointer targets in assignment differ in signedness" warnings - Update Debian packaging. - Fix up two issues with xfs_db and bmap. If the data/attr fork is local, it either infinite loops or crashes. If both are displayed, the attrs are wrong. - Fix up xfs_io mmap read that read from the wrong offset. - Updated xfs_io man page. - Fix up libxfs SEGV when attempting to mount a non-XFS filesystem. Thanks to Utako Kusaka for the above four fixes. - Fix up xfs_repair aborting if it finds an inode with an invalid inode type. - Fix up mkfs.xfs default realtime extent size for large block sizes. From owner-xfs@oss.sgi.com Wed Dec 13 07:07:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 13 Dec 2006 07:07:33 -0800 (PST) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBDF7Qqw017753 for ; Wed, 13 Dec 2006 07:07:27 -0800 Received: by py-out-1112.google.com with SMTP id p76so112532pyb for ; Wed, 13 Dec 2006 07:06:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=LmPJo/JfkjeDQp3SO0wPlHpTZ/aR5i9lQDiUHggMELRbdRSTSC/+RDPmXQg7HjmuUb3Gictfony0JhugxYas2BTYOUnf/RsiE/BtaFuLJoewWkAWPKmYmeVuuoZAjJtf/hYmGSNL6BzpMY6NBD2ggrnT0j6s1FafdjD2NZ02oXI= Received: by 10.35.69.11 with SMTP id w11mr1709514pyk.1166020803816; Wed, 13 Dec 2006 06:40:03 -0800 (PST) Received: by 10.35.125.5 with HTTP; Wed, 13 Dec 2006 06:40:03 -0800 (PST) Message-ID: <5d96567b0612130640s5bae22c8kdc6acad72661932b@mail.gmail.com> Date: Wed, 13 Dec 2006 16:40:03 +0200 From: "Raz Ben-Jehuda(caro)" To: xfs@oss.sgi.com Subject: xfs over linux raid5 perffered blocksize MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-archive-position: 9983 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: xfs Content-Length: 526 Lines: 20 Hello I need to create a writer which creates files over linux software raid5. the files must be aligned by the stripe unit and so as the extents. If an extent SIZE is not a factor of the stripe unit it is as if i have done nothing. I have learned by reading the documentatiom that the preffered io size is the stripe width. that seems to work. I am reserving space and writing 3MB size buffers to raid5 with 1MB stripe unit over 4 disks. my question: Can I rely on it ? Can I enforce this behaviour ? thank you -- Raz From owner-xfs@oss.sgi.com Thu Dec 14 10:05:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 14 Dec 2006 10:05:17 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBEI59qw014981 for ; Thu, 14 Dec 2006 10:05:11 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBEI4I9q010064 for ; Thu, 14 Dec 2006 13:04:18 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBEI4Ipa025732 for ; Thu, 14 Dec 2006 13:04:18 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBEI4HS1002807 for ; Thu, 14 Dec 2006 13:04:17 -0500 Message-ID: <45819221.70502@sandeen.net> Date: Thu, 14 Dec 2006 12:04:17 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] use vfs-defined file attribute flags Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9996 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1279 Lines: 33 the vfs finally has common flags defined for this stuff, rather than forcing filesystems to re-define what ext2 has already done. Seems like XFS could use them instead of open-coding them. Thanks, -Eric Signed-off-by: Eric Sandeen Index: linux-2.6.19/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6.19.orig/fs/xfs/linux-2.6/xfs_ioctl.c +++ linux-2.6.19/fs/xfs/linux-2.6/xfs_ioctl.c @@ -1095,11 +1095,11 @@ xfs_ioc_fsgeometry( /* * Linux extended inode flags interface. */ -#define LINUX_XFLAG_SYNC 0x00000008 /* Synchronous updates */ -#define LINUX_XFLAG_IMMUTABLE 0x00000010 /* Immutable file */ -#define LINUX_XFLAG_APPEND 0x00000020 /* writes to file may only append */ -#define LINUX_XFLAG_NODUMP 0x00000040 /* do not dump file */ -#define LINUX_XFLAG_NOATIME 0x00000080 /* do not update atime */ +#define LINUX_XFLAG_SYNC FS_SYNC_FL /* Synchronous updates */ +#define LINUX_XFLAG_IMMUTABLE FS_IMMUTABLE_FL /* Immutable file */ +#define LINUX_XFLAG_APPEND FS_APPEND_FL /* writes may only append */ +#define LINUX_XFLAG_NODUMP FS_NODUMP_FL /* do not dump file */ +#define LINUX_XFLAG_NOATIME FS_NOATIME_FL /* do not update atime */ STATIC unsigned int xfs_merge_ioc_xflags( From owner-xfs@oss.sgi.com Thu Dec 14 10:19:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 14 Dec 2006 10:20:00 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBEIJqqw018105 for ; Thu, 14 Dec 2006 10:19:53 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBEIIwUI016842; Thu, 14 Dec 2006 13:18:58 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBEIIubO029455; Thu, 14 Dec 2006 13:18:56 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBEIItiV004089; Thu, 14 Dec 2006 13:18:56 -0500 Message-ID: <4581958F.6070208@sandeen.net> Date: Thu, 14 Dec 2006 12:18:55 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] use vfs-defined file attribute flags References: <45819221.70502@sandeen.net> <20061214181500.GA13856@infradead.org> In-Reply-To: <20061214181500.GA13856@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9997 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 929 Lines: 20 Christoph Hellwig wrote: >> -#define LINUX_XFLAG_SYNC 0x00000008 /* Synchronous updates */ >> -#define LINUX_XFLAG_IMMUTABLE 0x00000010 /* Immutable file */ >> -#define LINUX_XFLAG_APPEND 0x00000020 /* writes to file may only append */ >> -#define LINUX_XFLAG_NODUMP 0x00000040 /* do not dump file */ >> -#define LINUX_XFLAG_NOATIME 0x00000080 /* do not update atime */ >> +#define LINUX_XFLAG_SYNC FS_SYNC_FL /* Synchronous updates */ >> +#define LINUX_XFLAG_IMMUTABLE FS_IMMUTABLE_FL /* Immutable file */ >> +#define LINUX_XFLAG_APPEND FS_APPEND_FL /* writes may only append */ >> +#define LINUX_XFLAG_NODUMP FS_NODUMP_FL /* do not dump file */ >> +#define LINUX_XFLAG_NOATIME FS_NOATIME_FL /* do not update atime */ > > Just kill the defines completly and use the FS_ flags. that probably would be better, I thought of that after I sent it. :) *shrug* whichever. It's heresy to suggest less indirection in xfs ;-) -Eric From owner-xfs@oss.sgi.com Thu Dec 14 10:22:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 14 Dec 2006 10:22:41 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBEIMUqw018801 for ; Thu, 14 Dec 2006 10:22:33 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBEILb52018009; Thu, 14 Dec 2006 13:21:37 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBEILaKi030210; Thu, 14 Dec 2006 13:21:36 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBEILaiO004381; Thu, 14 Dec 2006 13:21:36 -0500 Message-ID: <45819630.3070701@sandeen.net> Date: Thu, 14 Dec 2006 12:21:36 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] use vfs-defined file attribute flags References: <45819221.70502@sandeen.net> <20061214181500.GA13856@infradead.org> In-Reply-To: <20061214181500.GA13856@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 9998 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 2329 Lines: 67 Christoph Hellwig wrote: >> -#define LINUX_XFLAG_SYNC 0x00000008 /* Synchronous updates */ >> -#define LINUX_XFLAG_IMMUTABLE 0x00000010 /* Immutable file */ >> -#define LINUX_XFLAG_APPEND 0x00000020 /* writes to file may only append */ >> -#define LINUX_XFLAG_NODUMP 0x00000040 /* do not dump file */ >> -#define LINUX_XFLAG_NOATIME 0x00000080 /* do not update atime */ >> +#define LINUX_XFLAG_SYNC FS_SYNC_FL /* Synchronous updates */ >> +#define LINUX_XFLAG_IMMUTABLE FS_IMMUTABLE_FL /* Immutable file */ >> +#define LINUX_XFLAG_APPEND FS_APPEND_FL /* writes may only append */ >> +#define LINUX_XFLAG_NODUMP FS_NODUMP_FL /* do not dump file */ >> +#define LINUX_XFLAG_NOATIME FS_NOATIME_FL /* do not update atime */ >> > > Just kill the defines completly and use the FS_ flags > 1 file changed, 5 insertions(+), 10 deletions(-) Signed-off-by: Eric Sandeen Index: linux-2.6.19/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6.19.orig/fs/xfs/linux-2.6/xfs_ioctl.c +++ linux-2.6.19/fs/xfs/linux-2.6/xfs_ioctl.c @@ -1095,11 +1095,6 @@ xfs_ioc_fsgeometry( /* * Linux extended inode flags interface. */ -#define LINUX_XFLAG_SYNC 0x00000008 /* Synchronous updates */ -#define LINUX_XFLAG_IMMUTABLE 0x00000010 /* Immutable file */ -#define LINUX_XFLAG_APPEND 0x00000020 /* writes to file may only append */ -#define LINUX_XFLAG_NODUMP 0x00000040 /* do not dump file */ -#define LINUX_XFLAG_NOATIME 0x00000080 /* do not update atime */ STATIC unsigned int xfs_merge_ioc_xflags( @@ -1108,23 +1103,23 @@ xfs_merge_ioc_xflags( { unsigned int xflags = start; - if (flags & LINUX_XFLAG_IMMUTABLE) + if (flags & FS_IMMUTABLE_FL) xflags |= XFS_XFLAG_IMMUTABLE; else xflags &= ~XFS_XFLAG_IMMUTABLE; - if (flags & LINUX_XFLAG_APPEND) + if (flags & FS_APPEND_FL) xflags |= XFS_XFLAG_APPEND; else xflags &= ~XFS_XFLAG_APPEND; - if (flags & LINUX_XFLAG_SYNC) + if (flags & FS_SYNC_FL) xflags |= XFS_XFLAG_SYNC; else xflags &= ~XFS_XFLAG_SYNC; - if (flags & LINUX_XFLAG_NOATIME) + if (flags & FS_NOATIME_FL) xflags |= XFS_XFLAG_NOATIME; else xflags &= ~XFS_XFLAG_NOATIME; - if (flags & LINUX_XFLAG_NODUMP) + if (flags & FS_NODUMP_FL) xflags |= XFS_XFLAG_NODUMP; else xflags &= ~XFS_XFLAG_NODUMP; From owner-xfs@oss.sgi.com Thu Dec 14 10:35:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 14 Dec 2006 10:35:57 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBEIZlqw021217 for ; Thu, 14 Dec 2006 10:35:50 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1Guv6i-0003jV-Vv; Thu, 14 Dec 2006 18:15:01 +0000 Date: Thu, 14 Dec 2006 18:15:00 +0000 From: Christoph Hellwig To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: Re: [PATCH] use vfs-defined file attribute flags Message-ID: <20061214181500.GA13856@infradead.org> References: <45819221.70502@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45819221.70502@sandeen.net> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 9999 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 828 Lines: 22 > -#define LINUX_XFLAG_SYNC 0x00000008 /* Synchronous updates */ > -#define LINUX_XFLAG_IMMUTABLE 0x00000010 /* Immutable file */ > -#define LINUX_XFLAG_APPEND 0x00000020 /* writes to file may only append */ > -#define LINUX_XFLAG_NODUMP 0x00000040 /* do not dump file */ > -#define LINUX_XFLAG_NOATIME 0x00000080 /* do not update atime */ > +#define LINUX_XFLAG_SYNC FS_SYNC_FL /* Synchronous updates */ > +#define LINUX_XFLAG_IMMUTABLE FS_IMMUTABLE_FL /* Immutable file */ > +#define LINUX_XFLAG_APPEND FS_APPEND_FL /* writes may only append */ > +#define LINUX_XFLAG_NODUMP FS_NODUMP_FL /* do not dump file */ > +#define LINUX_XFLAG_NOATIME FS_NOATIME_FL /* do not update atime */ Just kill the defines completly and use the FS_ flags. > > STATIC unsigned int > xfs_merge_ioc_xflags( > > > > ---end quoted text--- From owner-xfs@oss.sgi.com Thu Dec 14 15:12:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 14 Dec 2006 15:12:58 -0800 (PST) Received: from coraid.com (ns1.coraid.com [65.14.39.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBENCkqw026804 for ; Thu, 14 Dec 2006 15:12:48 -0800 Received: from coraid.com ([205.185.197.207]) by coraid.com; Thu Dec 14 17:47:36 EST 2006 Date: Thu, 14 Dec 2006 17:48:26 -0500 From: "Ed L. Cashin" To: Andrew Morton Cc: support@coraid.com, Greg KH , boddingt@optusnet.com.au, xfs@oss.sgi.com, "bugme-daemon@kernel-bugs.osdl.org" Subject: Re: Fw: [Bugme-new] [Bug 7662] New: AOE filesystem corruption on Alpha Message-ID: <20061214224826.GI10048@coraid.com> Reply-To: support@coraid.com References: <20061209234305.c65b4e14.akpm@osdl.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="WplhKdTI2c8ulnbP" Content-Disposition: inline In-Reply-To: <20061209234305.c65b4e14.akpm@osdl.org> User-Agent: Mutt/1.5.11+cvs20060126 X-archive-position: 10002 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ecashin@coraid.com Precedence: bulk X-list: xfs Content-Length: 11770 Lines: 255 --WplhKdTI2c8ulnbP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Dec 09, 2006 at 11:43:05PM -0800, Andrew Morton wrote: > > hm, AOE on alpha - who'd have imagined? > > James, are you able to get us a copy of the oops trace? It turns out the aoe driver wasn't setting up the linear part of the skb correctly and so the data was being offset when the skb was linearized for cards that didn't do scatter gather. James Boddington reports that everything's fine with a RealTek 8139 card he has but not fine with several other cards: I just tried a cheap RealTek card. A rtl8139 pci 100MBit. AoE in 2.6.19 works with the realtek card. Did your test again with the realtek. The results look like the results I got with AoE v23. Correct offset and the data not truncated. Which leaves me with both ne2k-pci and 3com, AoE not working. Rtl8139 and AoE does work. I haven't got confirmation, but we think that the other cards don't perform scatter gather. We can replicate JB's problem by turning off the scatter gather feature in an Intel gigabit network card using ethtool. The attached patch fixes the offsets when scatter gather is not in use by setting up the linear part of the skb correctly. After applying this patch to 2.6.19.1, everything looks great for writes like: echo AaAbAcAdAe > /dev/etherd/e0.2 ... and when using ext3 on the device. However, we see problems when using XFS. It appears that the XFS problem is unrelated, because the kernel's new lock debugging sees some problems that appear in the attached netconsole log. XFS passes us a bio with a pointer to a page that has a reference count of zero which causes problems when __pskb_pull_tail does a put on the page. With ext3, we only got pages with a reference count greater than zero. The problem doesn't appear when scatter gather is turned on, although the same locking issues are logged. (See third attachment.) -- Ed L Cashin --WplhKdTI2c8ulnbP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="aoe-2.6.19-lenfix.diff" diff -uprN linux-2.6.19.orig/drivers/block/aoe/aoecmd.c linux-2.6.19.mod/drivers/block/aoe/aoecmd.c --- linux-2.6.19.orig/drivers/block/aoe/aoecmd.c 2006-12-11 18:15:42.322711000 -0500 +++ linux-2.6.19.mod/drivers/block/aoe/aoecmd.c 2006-12-12 17:12:59.307200500 -0500 @@ -30,8 +30,6 @@ new_skb(ulong len) skb->nh.raw = skb->mac.raw = skb->data; skb->protocol = __constant_htons(ETH_P_AOE); skb->priority = 0; - skb_put(skb, len); - memset(skb->head, 0, len); skb->next = skb->prev = NULL; /* tell the network layer not to perform IP checksums @@ -122,8 +120,8 @@ aoecmd_ata_rw(struct aoedev *d, struct f skb = f->skb; h = (struct aoe_hdr *) skb->mac.raw; ah = (struct aoe_atahdr *) (h+1); - skb->len = sizeof *h + sizeof *ah; - memset(h, 0, ETH_ZLEN); + skb_put(skb, sizeof *h + sizeof *ah); + memset(h, 0, skb->len); f->tag = aoehdr_atainit(d, h); f->waited = 0; f->buf = buf; @@ -149,7 +147,6 @@ aoecmd_ata_rw(struct aoedev *d, struct f skb->len += bcnt; skb->data_len = bcnt; } else { - skb->len = ETH_ZLEN; writebit = 0; } @@ -206,6 +203,7 @@ aoecmd_cfg_pkts(ushort aoemajor, unsigne printk(KERN_INFO "aoe: skb alloc failure\n"); continue; } + skb_put(skb, sizeof *h + sizeof *ch); skb->dev = ifp; if (sl_tail == NULL) sl_tail = skb; @@ -243,6 +241,7 @@ freeframe(struct aoedev *d) continue; if (atomic_read(&skb_shinfo(f->skb)->dataref) == 1) { skb_shinfo(f->skb)->nr_frags = f->skb->data_len = 0; + skb_trim(f->skb, 0); return f; } n++; @@ -698,8 +697,8 @@ aoecmd_ata_id(struct aoedev *d) skb = f->skb; h = (struct aoe_hdr *) skb->mac.raw; ah = (struct aoe_atahdr *) (h+1); - skb->len = ETH_ZLEN; - memset(h, 0, ETH_ZLEN); + skb_put(skb, sizeof *h + sizeof *ah); + memset(h, 0, skb->len); f->tag = aoehdr_atainit(d, h); f->waited = 0; --WplhKdTI2c8ulnbP Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfslocks.log" [17288.149493] Filesystem "etherd/e0.2": Disabling barriers, not supported by the underlying device [17288.162760] XFS mounting filesystem etherd/e0.2 [17296.743211] [17296.743214] ============================================= [17296.743236] [ INFO: possible recursive locking detected ] [17296.743246] 2.6.19.1dbg #2 [17296.743256] --------------------------------------------- [17296.743269] cp/8885 is trying to acquire lock: [17296.743281] (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x6e/0xa0 [xfs] [17296.743374] [17296.743376] but task is already holding lock: [17296.743397] (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x6e/0xa0 [xfs] [17296.743462] [17296.743464] other info that might help us debug this: [17296.743486] 2 locks held by cp/8885: [17296.743498] #0: (&inode->i_mutex/1){--..}, at: [] lookup_create+0x2f/0xa0 [17296.743594] #1: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x6e/0xa0 [xfs] [17296.743713] [17296.743714] stack backtrace: [17296.743725] [17296.743726] Call Trace: [17296.743744] [] dump_trace+0xa9/0x480 [17296.743756] [] show_trace+0x43/0x60 [17296.743773] [] dump_stack+0x15/0x20 [17296.743787] [] __lock_acquire+0x8b7/0xc80 [17296.743798] [] lock_acquire+0x8d/0xc0 [17296.743810] [] down_write+0x36/0x50 [17296.743841] [] :xfs:xfs_ilock+0x6e/0xa0 [17296.743898] [] :xfs:xfs_iget+0x462/0x870 [17296.743956] [] :xfs:xfs_trans_iget+0xbe/0x140 [17296.744026] [] :xfs:xfs_ialloc+0x9e/0x500 [17296.744083] [] :xfs:xfs_dir_ialloc+0x7c/0x2b0 [17296.744148] [] :xfs:xfs_mkdir+0x35b/0x6c0 [17296.744216] [] :xfs:xfs_vn_mknod+0x217/0x440 [17296.744290] [] :xfs:xfs_vn_mkdir+0xe/0x10 [17296.744348] [] vfs_mkdir+0xfc/0x190 [17296.744359] [] sys_mkdirat+0xb7/0x110 [17296.744371] [] sys_mkdir+0x13/0x20 [17296.744380] [] tracesys+0xdc/0xe7 [17296.744403] [<00000034db5bc617>] [17296.744410] [17296.765295] Bad page state in process 'cp' [17296.765298] page:ffff81003f1bf358 flags:0x0100000000000080 mapping:0000000000000000 mapcount:0 count:0 [17296.765300] Trying to fix it up, but a reboot is needed [17296.765301] Backtrace: [17296.765329] [17296.765330] Call Trace: [17296.765367] [] dump_trace+0xa9/0x480 [17296.765381] [] show_trace+0x43/0x60 [17296.765392] [] dump_stack+0x15/0x20 [17296.765407] [] bad_page+0x61/0x90 [17296.765420] [] free_hot_cold_page+0x8a/0x180 [17296.765431] [] free_hot_page+0xb/0x10 [17296.765446] [] put_page+0xa8/0xc0 [17296.765458] [] __pskb_pull_tail+0x211/0x2e0 [17296.765474] [] dev_queue_xmit+0xa6/0x2c0 [17296.765494] [] :aoe:aoenet_xmit+0x27/0x40 [17296.765504] Bad page state in process 'swapper' [17296.765509] page:ffff81003f1bf460 flags:0x010000000000008c mapping:0000000000000000 mapcount:0 count:0 [17296.765514] Trying to fix it up, but a reboot is needed [17296.765517] Backtrace: [17296.765521] [17296.765522] Call Trace: [17296.765534] [] dump_trace+0xa9/0x480 [17296.765543] [] show_trace+0x43/0x60 [17296.765551] [] dump_stack+0x15/0x20 [17296.765557] [] bad_page+0x61/0x90 [17296.765564] [] free_hot_cold_page+0x8a/0x180 [17296.765569] [] free_hot_page+0xb/0x10 [17296.765574] [] put_page+0xa8/0xc0 [17296.765583] [] __pskb_pull_tail+0x211/0x2e0 [17296.765590] [] dev_queue_xmit+0xa6/0x2c0 [17296.765602] [] :aoe:aoenet_xmit+0x27/0x40 [17296.765680] [] :xfs:xfs_buf_iorequest+0x424/0x4b0 [17296.765685] [] e1000_clean_rx_irq+0x498/0x550 [17296.765692] [] e1000_clean+0x98/0x130 [17296.765698] [] net_rx_action+0xc3/0x190 [17296.765707] [] __do_softirq+0x80/0x100 [17296.765716] [] call_softirq+0x1c/0x30 [17296.765726] [] do_softirq+0x3d/0xb0 [17296.765734] [] irq_exit+0x4e/0x60 [17296.765740] [] do_IRQ+0x15c/0x190 [17296.765747] [] ret_from_intr+0x0/0xf [17296.765753] [] mwait_idle_with_hints+0x4c/0x50 [17296.765763] [] mwait_idle+0x19/0x30 [17296.765768] [] cpu_idle+0x5b/0x80 [17296.765776] [] start_secondary+0x4eb/0x500 [17296.765781] [17296.765863] [] :xfs:xlog_bdstrat_cb+0x21/0x50 [17296.765619] [] :aoe:aoecmd_ata_rsp+0x66b/0x720 [17296.765627] [] :aoe:aoeblk_make_request+0x1d3/0x1f0 [17296.765635] [] generic_make_request+0x17e/0x1a0 [17296.765643] [] submit_bio+0xd8/0xf0 [17296.765660] [] :aoe:aoenet_rcv+0x13c/0x1a0 [17296.765673] [] netif_receive_skb+0x31c/0x350 [17296.765930] [] :xfs:xlog_state_release_iclog+0x353/0x550 [17296.765994] [] :xfs:xlog_write+0x684/0x740 [17296.766055] [] :xfs:xfs_log_write+0x38/0x70 [17296.766116] [] :xfs:_xfs_trans_commit+0x54e/0x760 [17296.766181] [] :xfs:xfs_create+0x4e6/0x6b0 [17296.766249] [] :xfs:xfs_vn_mknod+0x1ef/0x440 [17296.766325] [] :xfs:xfs_vn_create+0xb/0x10 [17296.766385] [] vfs_create+0x109/0x1a0 [17296.766398] [] open_namei+0x1cf/0x700 [17296.766409] [] do_filp_open+0x2c/0x50 [17296.766418] [] do_sys_open+0x5a/0xf0 [17296.766427] [] sys_open+0x1b/0x20 [17296.766437] [] tracesys+0xdc/0xe7 [17296.766473] [<00000034db5bc650>] [17296.766480] [17296.766526] Bad page state in process 'cp' [17296.766528] page:ffff81003f1bf3b0 flags:0x010000000000008c mapping:0000000000000000 mapcount:0 count:0 [17296.766530] Trying to fix it up, but a reboot is needed [17296.766531] Backtrace: [17296.766550] [17296.766551] Call Trace: [17296.766565] [] dump_trace+0xa9/0x480 [17296.766576] [] show_trace+0x43/0x60 [17296.766586] [] dump_stack+0x15/0x20 [17296.766597] [] bad_page+0x61/0x90 [17296.766607] [] free_hot_cold_page+0x8a/0x180 [17296.766618] [] free_hot_page+0xb/0x10 [17296.766629] [] put_page+0xa8/0xc0 [17296.766640] [] __pskb_pull_tail+0x211/0x2e0 [17296.766650] [] dev_queue_xmit+0xa6/0x2c0 [17296.766663] [] :aoe:aoenet_xmit+0x27/0x40 [17296.766677] [] :aoe:aoeblk_make_request+0x1d3/0x1f0 [17296.766688] [] generic_make_request+0x17e/0x1a0 [17296.766697] [] submit_bio+0xd8/0xf0 [17296.766731] [] :xfs:xfs_buf_iorequest+0x424/0x4b0 [17296.766804] [] :xfs:xlog_bdstrat_cb+0x21/0x50 [17296.766864] [] :xfs:xlog_state_release_iclog+0x353/0x550 [17296.766926] [] :xfs:xlog_write+0x684/0x740 --WplhKdTI2c8ulnbP-- From owner-xfs@oss.sgi.com Thu Dec 14 18:47:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 14 Dec 2006 18:48:02 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBF2lsqw023903 for ; Thu, 14 Dec 2006 18:47:56 -0800 Received: from [134.14.55.89] (soarer.melbourne.sgi.com [134.14.55.89]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23180; Fri, 15 Dec 2006 13:46:58 +1100 Message-ID: <45820D0E.3080702@sgi.com> Date: Fri, 15 Dec 2006 13:48:46 +1100 From: Vlad Apostolov User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com CC: linux-xfs@oss.sgi.com Subject: PARTIAL TAKE 959264: Workaround log space issue by increasing XFS_TRANS_PUSH_AIL_RESTARTS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10004 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: vapo@sgi.com Precedence: bulk X-list: xfs Content-Length: 593 Lines: 17 Workaround log space issue by increasing XFS_TRANS_PUSH_AIL_RESTARTS Date: Fri Dec 15 13:44:12 AEDT 2006 Workarea: soarer.melbourne.sgi.com:/home/vapo/isms/linux-xfs Inspected by: chatz Author: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27750a fs/xfs/xfs_trans_ail.c - 1.80 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_trans_ail.c.diff?r1=text&tr1=1.80&r2=text&tr2=1.79&f=h - pv 959264, rv chatz - Workaround log space issue by increasing XFS_TRANS_PUSH_AIL_RESTARTS From owner-xfs@oss.sgi.com Thu Dec 14 21:44:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 14 Dec 2006 21:44:10 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBF5hwqw014053 for ; Thu, 14 Dec 2006 21:44:00 -0800 Received: from [134.14.55.18] (dhcp18.melbourne.sgi.com [134.14.55.18]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA27012 for ; Fri, 15 Dec 2006 16:43:05 +1100 Message-ID: <458235E9.9060209@melbourne.sgi.com> Date: Fri, 15 Dec 2006 16:43:05 +1100 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: review: hopefully final attr2 corruption fixes Content-Type: multipart/mixed; boundary="------------060905020204050902090802" X-archive-position: 10005 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 15862 Lines: 434 This is a multi-part message in MIME format. --------------060905020204050902090802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: RE: attr2 Date: Fri, 15 Dec 2006 16:33:04 +1100 From: Barry Naujok To: 'Russell Cattelan' CC: 'Timothy Shimmin' , , 'Timothy Shimmin' , , 'David Chinner' I think I have it cracked now :) I've cleaned up a bit more as per Russell's comments. I also found another case of btree corruption when the last attribute is deleted (an attr2 optimization is to completely remove the attr fork when the last attribute is deleted). Also, the root btree is not modified anymore when an attribute goes just beyond the space the rest of the code thinks it needs (XFS_BMAP_ROOT_SPACE macro). Barry. > -----Original Message----- > From: Russell Cattelan [mailto:cattelan@thebarn.com] > Sent: Friday, 15 December 2006 2:31 PM > To: Barry Naujok > Cc: 'Timothy Shimmin'; chatz@melbourne.sgi.com; 'Timothy > Shimmin'; sandeen@sandeen.net; 'David Chinner' > Subject: Re: attr2 > > Barry Naujok wrote: > > > sorry just getting time to look at this again > > > > So looking over the latest patch I'm trying to understand > what is different from the original patch I sent out. > > I guess there is the addition of the calculation of number > of btree recs in the case of a the inode being converted > to an attr capable format. > I know we had talked about optimizing that space but it > leads into the guessing game we were talking about. > Will giving more space to attr be better or will leaving more > space for btree block be better. > > I would lean on the side of attrs are infrequent updates/additions > but data blocks are not. So opting for an attr1 half and half > split once > the inode goes btree for either fork seems simpler to me. > And keeps the code out of the guessing game of which fork > is better optimized by having more space. > > > My style point comment: > The current patch is a bit busy and has more calls to MAX, > the maxforkoff is a bit confusing since it contains bytes during > the calculation then converted back to the >> 3 value. > My orginal patch has the dsize variable to help clarify bytes vs > forkoff. > Hmm looking closer I also think there is replicated checks for > does the attr fit, the case statement doesn't need to deal > with "does the attr fit" since that is handled later. > Nothing really wrong with it but I just like the less line > of code approach. > > > > > > > > > > >>-----Original Message----- > >>From: Timothy Shimmin [mailto:timothy.shimmin@gmail.com] > >>Sent: Friday, 15 December 2006 1:08 PM > >>To: Barry Naujok > >>Cc: Russell Cattelan; chatz@melbourne.sgi.com; Timothy > >>Shimmin; sandeen@sandeen.net; David Chinner > >>Subject: Re: attr2 > >> > >>Hi Barry, > >> > >>I don't have the tree locally (can't do an xdiff) but > >>if we have data btree and existing forkoff then > >>you just set the minforkoff to the existing forkoff which > >>won't guarantee that the forkoff is not moved - previously > >>I was returning the forkoff in that case. > >> > >> > > > >Yes, good point. I was only thinking of the case of attrs > trying to get > >enlarged. I don't believe forkoff can be increased with the existing > >code, but with the attached change, it's now guaranteed. > > > > > > > >>Also comments could be fixed up a bit. > >> > >>The XFS_DINODE_FMT_EXTENTS comment has problems: > >>"in in the extents form will migrate to btree" > >>maybe you mean: > >>"in the data extents form migrating to btree" > >> > >>The XFS_DINODE_FMT_BTREE comment talks about setting the > >>forkoff but it is actually setting minforkoff. > >> > >> > > > >Hehe, that comment is unchanged from the previous patch, but > I've fixed > >it. > > > >There still seems to be an issue with a non-attribute > data-btree case, > >where adding a big-enough attribute will still cause the > btree to grow > >another level (not corrupted though), so it seems minforkoff in that > >case is not quite right. > > > > > > > >>--Tim > >> > >>On 12/15/06, Barry Naujok wrote: > >> > >> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Timothy Shimmin [mailto:timothy.shimmin@gmail.com] > >>>>Sent: Thursday, 14 December 2006 11:57 PM > >>>>To: Barry Naujok > >>>>Cc: Russell Cattelan; chatz@melbourne.sgi.com; Timothy > >>>>Shimmin; sandeen@sandeen.net; David Chinner > >>>>Subject: Re: attr2 > >>>> > >>>>Hi, > >>>> > >>>>On 12/14/06, Barry Naujok wrote: > >>>> > >>>> > >>>>>Made one interesting observation with the attr2 with a > >>>>> > >>>>> > >>inode full of > >> > >> > >>>>>extents that must be migrated to btree format, if the > >>>>> > >>>>> > >>xattr is big > >> > >> > >>>>>enough to go beyond the default forkoff (ie. < 15 in 256 > >>>>> > >>>>> > >>>>byte inode) but > >>>> > >>>> > >>>>>still stay inline, it won't, but go to extents. > >>>>> > >>>>>Eg: > >>>>> > >>>>> makeextents -b4096 -n 9 > >>>>> setfattr -n user.<32 chars> > >>>>> > >>>>>forkoff stays at 15, the data extents are btree as > >>>>> > >>>>> > >>expected, and the > >> > >> > >>>>>xattr is extents rather than local (shortform). > >>>>> > >>>>>I think a test is needed when creating the initial attr fork: > >>>>> > >>>>>xfs_bmap_add_attrfork() calls xfs_attr_shortform_bytesfit() > >>>>> > >>>>> > >>>>to determine > >>>> > >>>> > >>>>>the desired forkoff. As the inode is full at this stage > >>>>> > >>>>> > >>>>without an attr > >>>> > >>>> > >>>>>fork, it will definitely go btree. > >>>>> > >>>>> minforkoff = MAX(extents used, XFS_BMDR_SPACE_CALC()); > >>>>> > >>>>>I'm thinking if the inode doesn't have attrs at this stage, > >>>>> > >>>>> > >>>>it should > >>>> > >>>> > >>>>>base the minimum on XFS_BMDR_SPACE_CALC, rather than the > >>>>> > >>>>> > >>>>space currently > >>>> > >>>> > >>>>>used by extents. > >>>>> > >>>>>eg: > >>>>> > >>>>> minforkoff = XFS_BMDR_SPACE_CALC(MINDBTPTRS); > >>>>> if (dp->i_d.di_forkoff && xfs_ifork_dsize_used(dp) > >>>>>minforkoff) > >>>>> minforkoff = xfs_ifork_dsize_used(dp); > >>>>> > >>>>>Thoughts? > >>>>> > >>>>> > >>>>> > >>>>Did you mean this just if the data extents are in btree format? > >>>>You don't seem to be codifying the notion of > >>>>"full of extents that must be migrated to btree format". > >>>>No comparison of requested attr offset with the data space used > >>>>which would tell if we were going to have to force data > >>>>extents to btree. > >>>> > >>>>I guess there is no point in both going out of line if they > >>>>don't have to. > >>>>However, should we favour one over the other (EA over data). > >>>>I thought we were doing 1st come 1st served. > >>>>If data extents fit inline currently and then they still > >>>> > >>>> > >>fit inline > >> > >> > >>>>after EA added but > >>>>with EA out of line, then data wins. > >>>>But if data extents have to go out of line and we can > >>>>have attr inline then keep attr inline. > >>>> > >>>>It's late so I'm probably not thinking clearly ;-) > >>>> > >>>>--Tim > >>>> > >>>> > >>>Ok, I have implemented and tested the attached patch. I've > >>> > >>> > >>merged the > >> > >> > >>>function back in, distilling the core requirements. > >>> > >>>So, the main change from the previous patch is with data > >>> > >>> > >>extents format > >> > >> > >>>and no attr, it checks to see if adding the default attr > >>> > >>> > >>size (forkoff = > >> > >> > >>>15 for 256 byte inodes) will cause the data fork to be converted to > >>>btree format. If so, it will then set the minimum offset > to the base > >>>btree root size. > >>> > >>>So, with 7 extents, forkoff is allowed to go down to 14. > After that, > >>>forkoff will be back at 15 and the attrs go out-of-line. > >>> > >>>With 8 extents, adding any attr at all will cause the data > >>> > >>> > >>extents to go > >> > >> > >>>btree. This allows the attr to use up all the inode space > >>> > >>> > >>it can up to > >> > >> > >>>the btree root. > >>> > >>> > >>> > >>> > >>> > -- David Chatterton XFS Engineering Manager SGI Australia --------------060905020204050902090802 Content-Type: application/octet-stream; name="attr2_new.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attr2_new.diff" Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpmcy94ZnMveGZzX2F0 dHIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KCi0tLSBhL2Zz L3hmcy94ZnNfYXR0ci5jCTIwMDYtMTItMTUgMTY6MjU6NDYuMDAwMDAwMDAw ICsxMTAwCisrKyBiL2ZzL3hmcy94ZnNfYXR0ci5jCTIwMDYtMTItMTQgMTQ6 NTY6MDIuNTgwMjQ2NDc3ICsxMTAwCkBAIC0xOTksMTggKzE5OSwxNCBAQCB4 ZnNfYXR0cl9zZXRfaW50KHhmc19pbm9kZV90ICpkcCwgY29uc3QgCiAJCXJl dHVybiAoZXJyb3IpOwogCiAJLyoKLQkgKiBEZXRlcm1pbmUgc3BhY2UgbmV3 IGF0dHJpYnV0ZSB3aWxsIHVzZSwgYW5kIGlmIGl0IHdvdWxkIGJlCi0JICog ImxvY2FsIiBvciAicmVtb3RlIiAobm90ZTogbG9jYWwgIT0gaW5saW5lKS4K LQkgKi8KLQlzaXplID0geGZzX2F0dHJfbGVhZl9uZXdlbnRzaXplKG5hbWVs ZW4sIHZhbHVlbGVuLAotCQkJCQltcC0+bV9zYi5zYl9ibG9ja3NpemUsICZs b2NhbCk7Ci0KLQkvKgogCSAqIElmIHRoZSBpbm9kZSBkb2Vzbid0IGhhdmUg YW4gYXR0cmlidXRlIGZvcmssIGFkZCBvbmUuCiAJICogKGlub2RlIG11c3Qg bm90IGJlIGxvY2tlZCB3aGVuIHdlIGNhbGwgdGhpcyByb3V0aW5lKQogCSAq LwogCWlmIChYRlNfSUZPUktfUShkcCkgPT0gMCkgewotCQlpZiAoKGVycm9y ID0geGZzX2JtYXBfYWRkX2F0dHJmb3JrKGRwLCBzaXplLCByc3ZkKSkpCisJ CWludCBzZl9zaXplID0gc2l6ZW9mKHhmc19hdHRyX3NmX2hkcl90KSArCisJ CQkgICAgICBYRlNfQVRUUl9TRl9FTlRTSVpFX0JZTkFNRShuYW1lbGVuLCB2 YWx1ZWxlbik7CisKKwkJaWYgKChlcnJvciA9IHhmc19ibWFwX2FkZF9hdHRy Zm9yayhkcCwgc2Zfc2l6ZSwgcnN2ZCkpKQogCQkJcmV0dXJuKGVycm9yKTsK IAl9CiAKQEAgLTIzMSw2ICsyMjcsMTMgQEAgeGZzX2F0dHJfc2V0X2ludCh4 ZnNfaW5vZGVfdCAqZHAsIGNvbnN0IAogCWFyZ3MuYWRkbmFtZSA9IDE7CiAJ YXJncy5va25vZW50ID0gMTsKIAorCS8qCisJICogRGV0ZXJtaW5lIHNwYWNl IG5ldyBhdHRyaWJ1dGUgd2lsbCB1c2UsIGFuZCBpZiBpdCB3b3VsZCBiZQor CSAqICJsb2NhbCIgb3IgInJlbW90ZSIgKG5vdGU6IGxvY2FsICE9IGlubGlu ZSkuCisJICovCisJc2l6ZSA9IHhmc19hdHRyX2xlYWZfbmV3ZW50c2l6ZShu YW1lbGVuLCB2YWx1ZWxlbiwKKwkJCQkJbXAtPm1fc2Iuc2JfYmxvY2tzaXpl LCAmbG9jYWwpOworCiAJbmJsa3MgPSBYRlNfREFFTlRFUl9TUEFDRV9SRVMo bXAsIFhGU19BVFRSX0ZPUkspOwogCWlmIChsb2NhbCkgewogCQlpZiAoc2l6 ZSA+IChtcC0+bV9zYi5zYl9ibG9ja3NpemUgPj4gMSkpIHsKCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQpmcy94ZnMveGZzX2F0dHJfbGVhZi5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKLS0tIGEvZnMveGZz L3hmc19hdHRyX2xlYWYuYwkyMDA2LTEyLTE1IDE2OjI1OjQ2LjAwMDAwMDAw MCArMTEwMAorKysgYi9mcy94ZnMveGZzX2F0dHJfbGVhZi5jCTIwMDYtMTIt MTUgMTY6MjU6MjAuNjEyNDE2Mzg1ICsxMTAwCkBAIC0xNTAsNiArMTUwLDcg QEAgeGZzX2F0dHJfc2hvcnRmb3JtX2J5dGVzZml0KHhmc19pbm9kZV90IAog CWludCBvZmZzZXQ7CiAJaW50IG1pbmZvcmtvZmY7CS8qIGxvd2VyIGxpbWl0 IG9uIHZhbGlkIGZvcmtvZmYgbG9jYXRpb25zICovCiAJaW50IG1heGZvcmtv ZmY7CS8qIHVwcGVyIGxpbWl0IG9uIHZhbGlkIGZvcmtvZmYgbG9jYXRpb25z ICovCisJaW50IGRzaXplOwkKIAl4ZnNfbW91bnRfdCAqbXAgPSBkcC0+aV9t b3VudDsKIAogCW9mZnNldCA9IChYRlNfTElUSU5PKG1wKSAtIGJ5dGVzKSA+ PiAzOyAvKiByb3VuZGVkIGRvd24gKi8KQEAgLTE2OSw4ICsxNzAsNDMgQEAg eGZzX2F0dHJfc2hvcnRmb3JtX2J5dGVzZml0KHhmc19pbm9kZV90IAogCQly ZXR1cm4gMDsKIAl9CiAKLQkvKiBkYXRhIGZvcmsgYnRyZWUgcm9vdCBjYW4g aGF2ZSBhdCBsZWFzdCB0aGlzIG1hbnkga2V5L3B0ciBwYWlycyAqLwotCW1p bmZvcmtvZmYgPSBNQVgoZHAtPmlfZGYuaWZfYnl0ZXMsIFhGU19CTURSX1NQ QUNFX0NBTEMoTUlOREJUUFRSUykpOworCWRzaXplID0gZHAtPmlfZGYuaWZf Ynl0ZXM7CisJCisJc3dpdGNoIChkcC0+aV9kLmRpX2Zvcm1hdCkgeworCWNh c2UgWEZTX0RJTk9ERV9GTVRfRVhURU5UUzoKKwkJLyogCisJCSAqIElmIHRo ZXJlIGlzIG5vIGF0dHIgZm9yayBhbmQgdGhlIGRhdGEgZm9yayBpcyBleHRl bnRzLCAKKwkJICogZGV0ZXJtaW5lIGlmIGNyZWF0aW5nIHRoZSBkZWZhdWx0 IGF0dHIgZm9yayB3aWxsIHJlc3VsdCAKKwkJICogaW4gdGhlIGV4dGVudHMg Zm9ybSBtaWdyYXRpbmcgdG8gYnRyZWUuIElmIHNvLCB0aGUgCisJCSAqIG1p bmltdW0gb2Zmc2V0IG9ubHkgbmVlZHMgdG8gYmUgdGhlIHNwYWNlIHJlcXVp cmVkIGZvciAKKwkJICogdGhlIGJ0cmVlIHJvb3QuCisJCSAqLyAKKwkJaWYg KCFkcC0+aV9kLmRpX2ZvcmtvZmYgJiYgZHAtPmlfZGYuaWZfYnl0ZXMgPiBt cC0+bV9hdHRyb2Zmc2V0KQorCQkJZHNpemUgPSBYRlNfQk1EUl9TUEFDRV9D QUxDKE1JTkRCVFBUUlMpOworCQlicmVhazsKKwkJCisJY2FzZSBYRlNfRElO T0RFX0ZNVF9CVFJFRToKKwkJLyoKKwkJICogSWYgaGF2ZSBkYXRhIGJ0cmVl IHRoZW4ga2VlcCBmb3Jrb2ZmIGlmIHdlIGhhdmUgb25lLAorCQkgKiBvdGhl cndpc2Ugd2UgYXJlIGFkZGluZyBhIG5ldyBhdHRyLCBzbyB0aGVuIHdlIHNl dCAKKwkJICogbWluZm9ya29mZiB0byB3aGVyZSB0aGUgYnRyZWUgcm9vdCBj YW4gZmluaXNoIHNvIHdlIGhhdmUgCisJCSAqIHBsZW50eSBvZiByb29tIGZv ciBhdHRycworCQkgKi8KKwkJaWYgKGRwLT5pX2QuZGlfZm9ya29mZikgewor CQkJaWYgKG9mZnNldCA8IGRwLT5pX2QuZGlfZm9ya29mZikgCisJCQkJcmV0 dXJuIDA7CisJCQllbHNlIAorCQkJCXJldHVybiBkcC0+aV9kLmRpX2Zvcmtv ZmY7CisJCX0gZWxzZQorCQkJZHNpemUgPSBYRlNfQk1BUF9CUk9PVF9TUEFD RShkcC0+aV9kZi5pZl9icm9vdCk7CisJCWJyZWFrOworCX0KKwkKKwkvKiAK KwkgKiBBIGRhdGEgZm9yayBidHJlZSByb290IG11c3QgaGF2ZSBzcGFjZSBm b3IgYXQgbGVhc3QgCisJICogTUlOREJUUFRSUyBrZXkvcHRyIHBhaXJzIGlm IHRoZSBkYXRhIGZvcmsgaXMgc21hbGwgb3IgZW1wdHkuCisJICovCisJbWlu Zm9ya29mZiA9IE1BWChkc2l6ZSwgWEZTX0JNRFJfU1BBQ0VfQ0FMQyhNSU5E QlRQVFJTKSk7CiAJbWluZm9ya29mZiA9IHJvdW5kdXAobWluZm9ya29mZiwg OCkgPj4gMzsKIAogCS8qIGF0dHIgZm9yayBidHJlZSByb290IGNhbiBoYXZl IGF0IGxlYXN0IHRoaXMgbWFueSBrZXkvcHRyIHBhaXJzICovCkBAIC0zMzYs NyArMzcyLDggQEAgeGZzX2F0dHJfc2hvcnRmb3JtX3JlbW92ZSh4ZnNfZGFf YXJnc190IAogCSAqLwogCXRvdHNpemUgLT0gc2l6ZTsKIAlpZiAodG90c2l6 ZSA9PSBzaXplb2YoeGZzX2F0dHJfc2ZfaGRyX3QpICYmICFhcmdzLT5hZGRu YW1lICYmCi0JICAgIChtcC0+bV9mbGFncyAmIFhGU19NT1VOVF9BVFRSMikp IHsKKwkgICAgKG1wLT5tX2ZsYWdzICYgWEZTX01PVU5UX0FUVFIyKSAmJiAK KwkgICAgKGRwLT5pX2QuZGlfZm9ybWF0ICE9IFhGU19ESU5PREVfRk1UX0JU UkVFKSkgewogCQkvKgogCQkgKiBMYXN0IGF0dHJpYnV0ZSBub3cgcmVtb3Zl ZCwgcmV2ZXJ0IHRvIG9yaWdpbmFsCiAJCSAqIGlub2RlIGZvcm1hdCBtYWtp bmcgYWxsIGxpdGVyYWwgYXJlYSBhdmFpbGFibGUKQEAgLTc0OCw2ICs3ODUs NyBAQCB4ZnNfYXR0cl9zaG9ydGZvcm1fYWxsZml0KHhmc19kYWJ1Zl90ICpi CiAJCQkJKyBiZTE2X3RvX2NwdShuYW1lX2xvYy0+dmFsdWVsZW4pOwogCX0K IAlpZiAoKGRwLT5pX21vdW50LT5tX2ZsYWdzICYgWEZTX01PVU5UX0FUVFIy KSAmJgorCSAgICAoZHAtPmlfZC5kaV9mb3JtYXQgIT0gWEZTX0RJTk9ERV9G TVRfQlRSRUUpICYmCiAJICAgIChieXRlcyA9PSBzaXplb2Yoc3RydWN0IHhm c19hdHRyX3NmX2hkcikpKQogCQlyZXR1cm4oLTEpOwogCXJldHVybih4ZnNf YXR0cl9zaG9ydGZvcm1fYnl0ZXNmaXQoZHAsIGJ5dGVzKSk7CkBAIC03ODYs NiArODI0LDcgQEAgeGZzX2F0dHJfbGVhZl90b19zaG9ydGZvcm0oeGZzX2Rh YnVmX3QgKgogCiAJaWYgKGZvcmtvZmYgPT0gLTEpIHsKIAkJQVNTRVJUKGRw LT5pX21vdW50LT5tX2ZsYWdzICYgWEZTX01PVU5UX0FUVFIyKTsKKwkJQVNT RVJUKGRwLT5pX2QuZGlfZm9ybWF0ICE9IFhGU19ESU5PREVfRk1UX0JUUkVF KTsKIAogCQkvKgogCQkgKiBMYXN0IGF0dHJpYnV0ZSB3YXMgcmVtb3ZlZCwg cmV2ZXJ0IHRvIG9yaWdpbmFsCgo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KZnMveGZzL3hmc19ibWFwLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09CgotLS0gYS9mcy94ZnMveGZzX2JtYXAuYwkyMDA2LTEyLTE1 IDE2OjI1OjQ2LjAwMDAwMDAwMCArMTEwMAorKysgYi9mcy94ZnMveGZzX2Jt YXAuYwkyMDA2LTEyLTE0IDE0OjU2OjAyLjU5NDY1ODAzOCArMTEwMApAQCAt MzU0Myw2ICszNTQzLDcgQEAgeGZzX2JtYXBfZm9ya29mZl9yZXNldCgKIAlp ZiAod2hpY2hmb3JrID09IFhGU19BVFRSX0ZPUksgJiYKIAkgICAgKGlwLT5p X2QuZGlfZm9ybWF0ICE9IFhGU19ESU5PREVfRk1UX0RFVikgJiYKIAkgICAg KGlwLT5pX2QuZGlfZm9ybWF0ICE9IFhGU19ESU5PREVfRk1UX1VVSUQpICYm CisJICAgIChpcC0+aV9kLmRpX2Zvcm1hdCAhPSBYRlNfRElOT0RFX0ZNVF9C VFJFRSkgJiYKIAkgICAgKChtcC0+bV9hdHRyb2Zmc2V0ID4+IDMpID4gaXAt PmlfZC5kaV9mb3Jrb2ZmKSkgewogCQlpcC0+aV9kLmRpX2ZvcmtvZmYgPSBt cC0+bV9hdHRyb2Zmc2V0ID4+IDM7CiAJCWlwLT5pX2RmLmlmX2V4dF9tYXgg PSBYRlNfSUZPUktfRFNJWkUoaXApIC8KDQo= --------------060905020204050902090802-- From owner-xfs@oss.sgi.com Fri Dec 15 00:05:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 15 Dec 2006 00:05:54 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBF85iqw030947 for ; Fri, 15 Dec 2006 00:05:46 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1Gv7er-0008UW-FZ; Fri, 15 Dec 2006 07:39:05 +0000 Date: Fri, 15 Dec 2006 07:39:05 +0000 From: Christoph Hellwig To: "Ed L. Cashin" Cc: Andrew Morton , support@coraid.com, Greg KH , boddingt@optusnet.com.au, xfs@oss.sgi.com, "bugme-daemon@kernel-bugs.osdl.org" Subject: Re: Fw: [Bugme-new] [Bug 7662] New: AOE filesystem corruption on Alpha Message-ID: <20061215073905.GA31821@infradead.org> References: <20061209234305.c65b4e14.akpm@osdl.org> <20061214224826.GI10048@coraid.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061214224826.GI10048@coraid.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10006 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 733 Lines: 15 On Thu, Dec 14, 2006 at 05:48:26PM -0500, Ed L. Cashin wrote: > ... and when using ext3 on the device. However, we see problems when > using XFS. It appears that the XFS problem is unrelated, because the > kernel's new lock debugging sees some problems that appear in the > attached netconsole log. > > XFS passes us a bio with a pointer to a page that has a reference > count of zero which causes problems when __pskb_pull_tail does a put > on the page. With ext3, we only got pages with a reference count > greater than zero. It's a kmalloced page. The same can happen with ext3 aswell, but only when doing log recovery. The last time this came up (vs iscsi) the conclusion was that the driver needs to handle this case. From owner-xfs@oss.sgi.com Fri Dec 15 02:44:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 15 Dec 2006 02:44:55 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBFAiiqw020935 for ; Fri, 15 Dec 2006 02:44:46 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1GvAXV-0005MV-DH; Fri, 15 Dec 2006 10:43:41 +0000 Date: Fri, 15 Dec 2006 10:43:41 +0000 From: "'Christoph Hellwig'" To: "Chen, Kenneth W" Cc: "'Andrew Morton'" , Dmitriy Monakhov , "'Christoph Hellwig'" , Dmitriy Monakhov , linux-kernel@vger.kernel.org, Linux Memory Management , devel@openvz.org, xfs@oss.sgi.com Subject: Re: [PATCH] incorrect error handling inside generic_file_direct_write Message-ID: <20061215104341.GA20089@infradead.org> Mail-Followup-To: 'Christoph Hellwig' , "Chen, Kenneth W" , 'Andrew Morton' , Dmitriy Monakhov , Dmitriy Monakhov , linux-kernel@vger.kernel.org, Linux Memory Management , devel@openvz.org, xfs@oss.sgi.com References: <20061212024027.6c2a79d3.akpm@osdl.org> <000001c71e60$7df9e010$e434030a@amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c71e60$7df9e010$e434030a@amr.corp.intel.com> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10007 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 929 Lines: 33 > +ssize_t > +__generic_file_aio_write(struct kiocb *iocb, const struct iovec *iov, > + unsigned long nr_segs, loff_t pos) I'd still call this generic_file_aio_write_nolock. > + loff_t *ppos = &iocb->ki_pos; I'd rather use iocb->ki_pos directly in the few places ppos is referenced currently. > if (ret > 0 && ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { > - ssize_t err; > - > err = sync_page_range_nolock(inode, mapping, pos, ret); > if (err < 0) > ret = err; > } So we're doing the sync_page_range once in __generic_file_aio_write with i_mutex held. > mutex_lock(&inode->i_mutex); > - ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, > - &iocb->ki_pos); > + ret = __generic_file_aio_write(iocb, iov, nr_segs, pos); > mutex_unlock(&inode->i_mutex); > > if (ret > 0 && ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { And then another time after it's unlocked, this seems wrong. From owner-xfs@oss.sgi.com Fri Dec 15 03:07:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 15 Dec 2006 03:07:41 -0800 (PST) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBFB7Xqw024072 for ; Fri, 15 Dec 2006 03:07:34 -0800 Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id BC15DB8F81B for ; Fri, 15 Dec 2006 11:36:49 +0100 (CET) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02698-09 for ; Fri, 15 Dec 2006 11:36:47 +0100 (CET) Received: from bliss.uni-koblenz.de (bliss.uni-koblenz.de [141.26.64.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id C14C8B8FAD3 for ; Fri, 15 Dec 2006 11:36:47 +0100 (CET) From: Rainer Krienke To: xfs@oss.sgi.com Subject: LEAFN node level is 1 warning in xfs_repair Date: Fri, 15 Dec 2006 11:36:46 +0100 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7248808.pHeuGFeSMS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612151136.47182.krienke@uni-koblenz.de> X-archive-position: 10009 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: krienke@uni-koblenz.de Precedence: bulk X-list: xfs Content-Length: 1510 Lines: 49 --nextPart7248808.pHeuGFeSMS Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I have a xfs filesystem on a SuSE SLES10 (kernel 2.6.16.21) system that was= =20 created just a week ago. Because I wanted to know how long it might take to= =20 run xfs_repair in case it might be needed I started xfs_repair on it withou= t=20 that I thought I would actually need it. Now for several inodes xfs_repair reports in Phase 3 and 4=20 LEAFN node level is 1=20 warning. In the mailinglists I found that other people have the same=20 experience.=20 The question is, if this warning anything serious that might lead into a=20 filesystem corruption later. Or can I just forget about this warning? Thanks Rainer --=20 --------------------------------------------------------------------------- Rainer Krienke, Universitaet Koblenz, Rechenzentrum, Raum A022 Universitaetsstrasse 1, 56070 Koblenz, Tel: +49 261287 -1312, Fax: -1001312 Mail: krienke@uni-koblenz.de, Web: http://www.uni-koblenz.de/~krienke Get my public PGP key: http://www.uni-koblenz.de/~krienke/mypgp.html --------------------------------------------------------------------------- --nextPart7248808.pHeuGFeSMS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBFgnq/aldtjc/KDEoRAqufAJ45aPnItnLemRloOImjo7UsSItUDwCdHfF/ nk4IjD0bcpxkYxF1+qyydVQ= =Y2X/ -----END PGP SIGNATURE----- --nextPart7248808.pHeuGFeSMS-- From owner-xfs@oss.sgi.com Fri Dec 15 05:54:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 15 Dec 2006 05:54:49 -0800 (PST) Received: from web32704.mail.mud.yahoo.com (web32704.mail.mud.yahoo.com [68.142.207.248]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBFDseqw015233 for ; Fri, 15 Dec 2006 05:54:41 -0800 Received: (qmail 94868 invoked by uid 60001); 15 Dec 2006 12:53:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=ZLa2RcFoIDpRcBPe4wEOAh86G2t2KUcmceui/detyYkY1In7yeBz5F5rvr3nDSrXPGiEhpYhfkAuUMs32Q6pd1w+NgatNVjFSwRajCl9Ct6jttrtzqgLvhP/rF13fheMUQ9jgVHrcbWwtig2H2lUOl6Ku5ao6CrsRZCuDtEC6lU=; X-YMail-OSG: hXfpk64VM1kEsKGQmgMiFOke0OUuSx_Uu9AX0kywH7OE23RaQDcHd3ZOK0lvpUttWoGfaiC9Bqc5gLYA0l858_VoQT1fKsY6w0OWK2tPgYlKP3K0D9pmqGEo2F0.SGe1r3J3nvr2rsKbGQ-- Received: from [128.222.37.21] by web32704.mail.mud.yahoo.com via HTTP; Fri, 15 Dec 2006 04:53:49 PST Date: Fri, 15 Dec 2006 04:53:49 -0800 (PST) From: chandrasekar mahalingam Subject: not able to create XFS filesystem To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <743683.94860.qm@web32704.mail.mud.yahoo.com> X-archive-position: 10010 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sekar1175@yahoo.com Precedence: bulk X-list: xfs Content-Length: 644 Lines: 25 Hi my RHEL 4 machine (Linux spea44 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:32:02 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux) has the rpm installed for XFS . xorg-x11-xfs-6.8.2-1.EL.13.36 and xorg-x11-libs-6.8.2-1.EL.13.36 when i try to create a file system using "mkfs -t xfs /dev/sekarvg/simple1" it says "mkfs.XFS: No such file or directory" . "lsmod|grep -i xfs " does not list xfs . Please let me know as what needs to be done to proceed further. Thanks & Regards M.Chandrasekar. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-xfs@oss.sgi.com Fri Dec 15 06:32:33 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 15 Dec 2006 06:32:40 -0800 (PST) Received: from smtp2.belwue.de (smtp2.belwue.de [129.143.2.15]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBFEWRqw019608 for ; Fri, 15 Dec 2006 06:32:28 -0800 Received: from scmail.science-computing.de (blackhole.science-computing.de [193.197.16.3]) by smtp2.belwue.de with ESMTP id kBFEHU63028101 for ; Fri, 15 Dec 2006 15:17:33 +0100 (MET) env-from (a.apprich@science-computing.de) Received: from localhost (localhost [127.0.0.1]) by scmail.science-computing.de (Postfix) with ESMTP id 509FC715E3F1 for ; Fri, 15 Dec 2006 15:17:28 +0100 (CET) Received: from scmail.science-computing.de ([127.0.0.1]) by localhost (obitest [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25200-02 for ; Fri, 15 Dec 2006 15:17:23 +0100 (CET) Received: from [10.10.16.1] (elmstreet.science-computing.de [10.10.16.1]) by scmail.science-computing.de (Postfix) with ESMTP id CCF7170F72B4 for ; Fri, 15 Dec 2006 15:17:23 +0100 (CET) Message-ID: <4582AE73.9080409@science-computing.de> Date: Fri, 15 Dec 2006 15:17:23 +0100 From: Alexander Apprich Organization: science + computing ag User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 Cc: xfs@oss.sgi.com Subject: Re: not able to create XFS filesystem References: <743683.94860.qm@web32704.mail.mud.yahoo.com> In-Reply-To: <743683.94860.qm@web32704.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10011 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: a.apprich@science-computing.de Precedence: bulk X-list: xfs Content-Length: 707 Lines: 32 Hi, chandrasekar mahalingam wrote: > Hi > my RHEL 4 machine (Linux spea44 2.6.9-42.ELsmp #1 > SMP Wed Jul 12 23:32:02 EDT 2006 x86_64 x86_64 x86_64 > GNU/Linux) has the rpm installed for XFS . > > xorg-x11-xfs-6.8.2-1.EL.13.36 and > xorg-x11-libs-6.8.2-1.EL.13.36 > those packages have nothing to do with the XFS filesystem :-) > when i try to create a file system using > "mkfs -t xfs /dev/sekarvg/simple1" it says "mkfs.XFS: > No such file or directory" . "lsmod|grep -i xfs " does > not list xfs . > AFAIK the XFS filesystem isn't officially supported by RedHat. You might get them from someplace else like http://atrpms.net/dist/el4/ But the kernel also need to support xfs. Hth Alex From owner-xfs@oss.sgi.com Fri Dec 15 06:57:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 15 Dec 2006 06:57:51 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBFEvhqw022241 for ; Fri, 15 Dec 2006 06:57:44 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id F08DD18021235; Fri, 15 Dec 2006 08:56:52 -0600 (CST) Message-ID: <4582B7B4.9070803@sandeen.net> Date: Fri, 15 Dec 2006 08:56:52 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alexander Apprich CC: xfs@oss.sgi.com Subject: Re: not able to create XFS filesystem References: <743683.94860.qm@web32704.mail.mud.yahoo.com> <4582AE73.9080409@science-computing.de> In-Reply-To: <4582AE73.9080409@science-computing.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10012 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1297 Lines: 50 Alexander Apprich wrote: > Hi, > > chandrasekar mahalingam wrote: >> Hi >> my RHEL 4 machine (Linux spea44 2.6.9-42.ELsmp #1 >> SMP Wed Jul 12 23:32:02 EDT 2006 x86_64 x86_64 x86_64 >> GNU/Linux) has the rpm installed for XFS . >> xorg-x11-xfs-6.8.2-1.EL.13.36 and >> xorg-x11-libs-6.8.2-1.EL.13.36 >> > > those packages have nothing to do with the XFS filesystem :-) *nod* that's xwindows. >> when i try to create a file system using >> "mkfs -t xfs /dev/sekarvg/simple1" it says "mkfs.XFS: >> No such file or directory" . "lsmod|grep -i xfs " does >> not list xfs . > > AFAIK the XFS filesystem isn't officially supported by > RedHat. You might get them from someplace else like It's not officially or unofficially supported. It's completely not supported and not present. If you really need supported xfs in RHEL you'll have to ask Red Hat for that, and I wish you luck. :) > http://atrpms.net/dist/el4/ Or http://sandeen.net/rhel4_xfs that contains a module rpm so you can run xfs in the stock RHEL kernel. you'll need userspace too, probably simplest to get a recent xfsprogs src.rpm from FC6 and the rpmbuild --rebuild xfsprogs-.src.rpm The above combination should work well for you. -Eric > But the kernel also need to support xfs. > > > Hth > > Alex > > From owner-xfs@oss.sgi.com Fri Dec 15 10:54:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 15 Dec 2006 10:54:19 -0800 (PST) Received: from mga01.intel.com ([192.55.52.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBFIs8qw024312 for ; Fri, 15 Dec 2006 10:54:10 -0800 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 15 Dec 2006 10:53:18 -0800 Received: from kwchen-mobl1.amr.corp.intel.com (HELO kwchenmobl1) ([10.3.52.208]) by fmsmga001.fm.intel.com with ESMTP; 15 Dec 2006 10:53:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,176,1165219200"; d="scan'208"; a="178003108:sNHT19576410" From: "Chen, Kenneth W" To: "'Christoph Hellwig'" Cc: "'Andrew Morton'" , "Dmitriy Monakhov" , "Dmitriy Monakhov" , , "Linux Memory Management" , , Subject: RE: [PATCH] incorrect error handling inside generic_file_direct_write Date: Fri, 15 Dec 2006 10:53:18 -0800 Message-ID: <000101c7207a$48c138f0$ff0da8c0@amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccgNeVMqKQOA+ZxSnqXd8lrl7/6aQAQ02YA In-Reply-To: <20061215104341.GA20089@infradead.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-archive-position: 10014 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kenneth.w.chen@intel.com Precedence: bulk X-list: xfs Content-Length: 1358 Lines: 42 Christoph Hellwig wrote on Friday, December 15, 2006 2:44 AM > So we're doing the sync_page_range once in __generic_file_aio_write > with i_mutex held. > > > > mutex_lock(&inode->i_mutex); > > - ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, > > - &iocb->ki_pos); > > + ret = __generic_file_aio_write(iocb, iov, nr_segs, pos); > > mutex_unlock(&inode->i_mutex); > > > > if (ret > 0 && ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { > > And then another time after it's unlocked, this seems wrong. I didn't invent that mess though. I should've ask the question first: in 2.6.20-rc1, generic_file_aio_write will call sync_page_range twice, once from __generic_file_aio_write_nolock and once within the function itself. Is it redundant? Can we delete the one in the top level function? Like the following? --- ./mm/filemap.c.orig 2006-12-15 09:02:58.000000000 -0800 +++ ./mm/filemap.c 2006-12-15 09:03:19.000000000 -0800 @@ -2370,14 +2370,6 @@ ssize_t generic_file_aio_write(struct ki ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, &iocb->ki_pos); mutex_unlock(&inode->i_mutex); - - if (ret > 0 && ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { - ssize_t err; - - err = sync_page_range(inode, mapping, pos, ret); - if (err < 0) - ret = err; - } return ret; } EXPORT_SYMBOL(generic_file_aio_write); From owner-xfs@oss.sgi.com Fri Dec 15 13:42:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 15 Dec 2006 13:42:51 -0800 (PST) Received: from coraid.com (ns1.coraid.com [65.14.39.133]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBFLgfqw010026 for ; Fri, 15 Dec 2006 13:42:42 -0800 Received: from coraid.com ([205.185.197.207]) by coraid.com; Fri Dec 15 16:36:05 EST 2006 Date: Fri, 15 Dec 2006 16:37:03 -0500 From: "Ed L. Cashin" To: Christoph Hellwig Cc: Andrew Morton , support@coraid.com, Greg KH , boddingt@optusnet.com.au, xfs@oss.sgi.com, "bugme-daemon@kernel-bugs.osdl.org" Subject: Re: Fw: [Bugme-new] [Bug 7662] New: AOE filesystem corruption on Alpha Message-ID: <20061215213703.GN15592@coraid.com> Reply-To: support@coraid.com References: <20061209234305.c65b4e14.akpm@osdl.org> <20061214224826.GI10048@coraid.com> <20061215073905.GA31821@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061215073905.GA31821@infradead.org> User-Agent: Mutt/1.5.11+cvs20060126 X-archive-position: 10015 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ecashin@coraid.com Precedence: bulk X-list: xfs Content-Length: 595 Lines: 17 On Fri, Dec 15, 2006 at 07:39:05AM +0000, Christoph Hellwig wrote: ... > It's a kmalloced page. The same can happen with ext3 aswell, but only > when doing log recovery. The last time this came up (vs iscsi) the > conclusion was that the driver needs to handle this case. I found this conversation: Subject: tcp_sendpage and page allocation lifetime vs. iscsi Date: 2005-04-25 17:02:59 GMT (1 year, 33 weeks, 2 days, 21 hours and 57 minutes ago) http://article.gmane.org/gmane.linux.kernel/298377 Do you have another conversation in mind? -- Ed L Cashin From owner-xfs@oss.sgi.com Sat Dec 16 07:33:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 16 Dec 2006 07:33:07 -0800 (PST) Received: from netcenter.hu (ns.netcenter.hu [195.228.254.57]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBGFWuqw024448 for ; Sat, 16 Dec 2006 07:32:59 -0800 Received: from dcccs (dsl5401D1D5.pool.t-online.hu [84.1.209.213]) by netcenter.hu (8.13.4/8.12.8) with SMTP id kBGFTNE2013692; Sat, 16 Dec 2006 16:29:23 +0100 Message-ID: <000d01c72127$3d7509b0$0400a8c0@dcccs> From: =?UTF-8?Q?Haar_J=C3=A1nos?= To: =?UTF-8?Q?Haar_J=C3=A1nos?= Cc: , References: <003701c71d78$33ed28d0$0400a8c0@dcccs> <00ab01c71e53$942af2f0$0400a8c0@dcccs> Subject: Re: xfslogd-spinlock bug? Date: Sat, 16 Dec 2006 12:19:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-archive-position: 10019 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 14167 Lines: 361 Hi I have some news. I dont know there is a context between 2 messages, but i can see, the spinlock bug comes always on cpu #3. Somebody have any idea? Thanks Janos Dec 16 11:42:48 dy-base BUG: warning at mm/truncate.c:398/invalidate_inode_pages2_range() Dec 16 11:42:49 dy-base Dec 16 11:42:49 dy-base Call Trace: Dec 16 11:42:49 dy-base [] invalidate_inode_pages2_range+0x285/0x2b8 Dec 16 11:42:49 dy-base [] _spin_unlock+0x9/0xb Dec 16 11:42:49 dy-base [] nfs_sync_inode_wait+0x1ab/0x1bd Dec 16 11:42:49 dy-base [] invalidate_inode_pages2+0xf/0x11 Dec 16 11:42:49 dy-base [] nfs_revalidate_mapping+0xa0/0x152 Dec 16 11:42:49 dy-base [] nfs_file_read+0x6e/0xbe Dec 16 11:42:49 dy-base [] do_sync_read+0xe2/0x126 Dec 16 11:42:49 dy-base [] unlock_kernel+0x35/0x37 Dec 16 11:42:49 dy-base [] autoremove_wake_function+0x0/0x38 Dec 16 11:42:49 dy-base [] nameidata_to_filp+0x2d/0x3e Dec 16 11:42:49 dy-base [] poison_obj+0x27/0x32 Dec 16 11:42:49 dy-base [] cache_free_debugcheck+0x1c6/0x1d6 Dec 16 11:42:49 dy-base [] putname+0x37/0x39 Dec 16 11:42:49 dy-base [] vfs_read+0xcc/0x172 Dec 16 11:42:49 dy-base [] sys_pread64+0x55/0x76 Dec 16 11:42:49 dy-base [] system_call+0x7e/0x83 Dec 16 11:42:49 dy-base .... Dec 16 12:08:36 dy-base BUG: spinlock bad magic on CPU#3, xfslogd/3/317 Dec 16 12:08:36 dy-base general protection fault: 0000 [1] Dec 16 12:08:36 dy-base SMP Dec 16 12:08:36 dy-base Dec 16 12:08:36 dy-base CPU 3 Dec 16 12:08:36 dy-base Dec 16 12:08:36 dy-base Modules linked in: Dec 16 12:08:36 dy-base nbd Dec 16 12:08:36 dy-base rd Dec 16 12:08:36 dy-base netconsole Dec 16 12:08:36 dy-base e1000 Dec 16 12:08:36 dy-base video Dec 16 12:08:36 dy-base Dec 16 12:08:36 dy-base Pid: 317, comm: xfslogd/3 Not tainted 2.6.19 #1 Dec 16 12:08:36 dy-base RIP: 0010:[] Dec 16 12:08:36 dy-base [] spin_bug+0x69/0xdf Dec 16 12:08:36 dy-base RSP: 0018:ffff81011fdedbc0 EFLAGS: 00010002 Dec 16 12:08:36 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 Dec 16 12:08:36 dy-base RDX: ffffffff807f3be2 RSI: 0000000000000082 RDI: 0000000100000000 Dec 16 12:08:36 dy-base RBP: ffff81011fdedbe0 R08: 0000000000006eb2 R09: 000000006b6b6b6b Dec 16 12:08:36 dy-base R10: 0000000000000082 R11: ffff81000584d280 R12: ffff810081476098 Dec 16 12:08:36 dy-base R13: ffffffff80642dc6 R14: 0000000000000000 R15: 0000000000000003 Dec 16 12:08:36 dy-base FS: 0000000000000000(0000) GS:ffff81011fc76b90(0000) knlGS:0000000000000000 Dec 16 12:08:36 dy-base CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Dec 16 12:08:36 dy-base CR2: 00002afc7d3ea000 CR3: 0000000117afc000 CR4: 00000000000006e0 Dec 16 12:08:36 dy-base Process xfslogd/3 (pid: 317, threadinfo ffff81011fdec000, task ffff81011fafc140) Dec 16 12:08:36 dy-base Stack: Dec 16 12:08:36 dy-base ffff81011fdedbe0 Dec 16 12:08:36 dy-base ffff810081476098 Dec 16 12:08:36 dy-base 0000000000000000 Dec 16 12:08:36 dy-base 0000000000000000 Dec 16 12:08:36 dy-base Dec 16 12:08:36 dy-base ffff81011fdedc10 Dec 16 12:08:36 dy-base ffffffff803f3bdc Dec 16 12:08:36 dy-base 0000000000000282 Dec 16 12:08:36 dy-base 0000000000000000 Dec 16 12:08:36 dy-base Dec 16 12:08:36 dy-base 0000000000000000 Dec 16 12:08:36 dy-base 0000000000000000 Dec 16 12:08:36 dy-base ffff81011fdedc30 Dec 16 12:08:36 dy-base ffffffff805e7f2b Dec 16 12:08:36 dy-base Dec 16 12:08:36 dy-base Call Trace: Dec 16 12:08:36 dy-base [] _raw_spin_lock+0x23/0xf1 Dec 16 12:08:36 dy-base [] _spin_lock_irqsave+0x11/0x18 Dec 16 12:08:36 dy-base [] __wake_up+0x22/0x50 Dec 16 12:08:36 dy-base [] xfs_buf_unpin+0x21/0x23 Dec 16 12:08:36 dy-base [] xfs_buf_item_unpin+0x2e/0xa6 Dec 16 12:08:36 dy-base [] xfs_trans_chunk_committed+0xc3/0xf7 Dec 16 12:08:37 dy-base [] xfs_trans_committed+0x49/0xde Dec 16 12:08:37 dy-base [] xlog_state_do_callback+0x185/0x33f Dec 16 12:08:37 dy-base [] xlog_iodone+0x104/0x131 Dec 16 12:08:37 dy-base [] xfs_buf_iodone_work+0x1a/0x3e Dec 16 12:08:37 dy-base [] worker_thread+0x0/0x134 Dec 16 12:08:37 dy-base [] run_workqueue+0xa8/0xf8 Dec 16 12:08:37 dy-base [] xfs_buf_iodone_work+0x0/0x3e Dec 16 12:08:37 dy-base [] worker_thread+0x0/0x134 Dec 16 12:08:37 dy-base [] worker_thread+0xfb/0x134 Dec 16 12:08:37 dy-base [] default_wake_function+0x0/0xf Dec 16 12:08:37 dy-base [] worker_thread+0x0/0x134 Dec 16 12:08:37 dy-base [] kthread+0xd8/0x10b Dec 16 12:08:37 dy-base [] schedule_tail+0x45/0xa6 Dec 16 12:08:37 dy-base [] child_rip+0xa/0x12 Dec 16 12:08:37 dy-base [] worker_thread+0x0/0x134 Dec 16 12:08:37 dy-base [] kthread+0x0/0x10b Dec 16 12:08:38 dy-base [] child_rip+0x0/0x12 Dec 16 12:08:38 dy-base Dec 16 12:08:38 dy-base Dec 16 12:08:38 dy-base Code: Dec 16 12:08:38 dy-base 8b Dec 16 12:08:38 dy-base 83 Dec 16 12:08:38 dy-base 0c Dec 16 12:08:38 dy-base 01 Dec 16 12:08:38 dy-base 00 Dec 16 12:08:38 dy-base 00 Dec 16 12:08:38 dy-base 48 Dec 16 12:08:38 dy-base 8d Dec 16 12:08:38 dy-base 8b Dec 16 12:08:38 dy-base 98 Dec 16 12:08:38 dy-base 02 Dec 16 12:08:38 dy-base 00 Dec 16 12:08:38 dy-base 00 Dec 16 12:08:38 dy-base 41 Dec 16 12:08:38 dy-base 8b Dec 16 12:08:38 dy-base 54 Dec 16 12:08:38 dy-base 24 Dec 16 12:08:38 dy-base 04 Dec 16 12:08:38 dy-base 41 Dec 16 12:08:38 dy-base 89 Dec 16 12:08:38 dy-base Dec 16 12:08:38 dy-base RIP Dec 16 12:08:38 dy-base [] spin_bug+0x69/0xdf Dec 16 12:08:38 dy-base RSP Dec 16 12:08:38 dy-base Dec 16 12:08:38 dy-base Kernel panic - not syncing: Fatal exception Dec 16 12:08:38 dy-base Dec 16 12:08:38 dy-base Rebooting in 5 seconds.. ----- Original Message ----- From: "Haar János" To: "Justin Piszcz" Cc: ; Sent: Wednesday, December 13, 2006 2:11 AM Subject: Re: xfslogd-spinlock bug? > Hello, Justin, > > This is a 64bit system. > > But i cannot understand, what is the curious? :-) > > I am not a kernel developer, and not a C programmer, but the long pointers > shows me, the 64 bit. > Or am i on the wrong clue? :-) > > Anyway, this issue happens for me about daily, or max 2-3 day often. > But i have no idea what cause this exactly. > The 2.6.16.18 was stable for me a long time, and one day starts to tricking > me, and happens more and more often. > Thats why i thinking some bad part of the (14TB) FS on the disks. > > (this fs have a lot of errors, what the xfs_repair cannot be corrected, but > anyway this is a productive system, and works well, except this issue. > Some months before i have replaced the parity disk in one of the RAID4 > array, and the next day, during the resync process, another one disk died. > I almost lost everything, but thanks to the raid4, and mdadm, i have > successfully recovered a lot of data with the 1 day older parity-only drive. > This was really bad, and leave some scars on the fs. ) > > This issue looks like for me a race condition between the cpus. (2x Xeon HT) > > Am i right? :-) > > Thanks, > > Janos > > > > > ----- Original Message ----- > From: "Justin Piszcz" > To: "Haar János" > Cc: ; > Sent: Tuesday, December 12, 2006 3:32 PM > Subject: Re: xfslogd-spinlock bug? > > > I'm not sure what is causing this problem but I was curious is this on a > 32bit or 64bit platform? > > Justin. > > On Tue, 12 Dec 2006, Haar János wrote: > > > Hello, list, > > > > I am the "big red button men" with the one big 14TB xfs, if somebody can > > remember me. :-) > > > > Now i found something in the 2.6.16.18, and try the 2.6.18.4, and the > > 2.6.19, but the bug still exists: > > > > Dec 11 22:47:21 dy-base BUG: spinlock bad magic on CPU#3, xfslogd/3/317 > > Dec 11 22:47:21 dy-base general protection fault: 0000 [1] > > Dec 11 22:47:21 dy-base SMP > > Dec 11 22:47:21 dy-base > > Dec 11 22:47:21 dy-base CPU 3 > > Dec 11 22:47:21 dy-base > > Dec 11 22:47:21 dy-base Modules linked in: > > Dec 11 22:47:21 dy-base nbd > > Dec 11 22:47:21 dy-base rd > > Dec 11 22:47:21 dy-base netconsole > > Dec 11 22:47:21 dy-base e1000 > > Dec 11 22:47:21 dy-base video > > Dec 11 22:47:21 dy-base > > Dec 11 22:47:21 dy-base Pid: 317, comm: xfslogd/3 Not tainted 2.6.19 #1 > > Dec 11 22:47:21 dy-base RIP: 0010:[] > > Dec 11 22:47:21 dy-base [] spin_bug+0x69/0xdf > > Dec 11 22:47:21 dy-base RSP: 0018:ffff81011fb89bc0 EFLAGS: 00010002 > > Dec 11 22:47:21 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: > > 0000000000000000 > > Dec 11 22:47:21 dy-base RDX: ffffffff808137a0 RSI: 0000000000000082 RDI: > > 0000000100000000 > > Dec 11 22:47:21 dy-base RBP: ffff81011fb89be0 R08: 0000000000026a70 R09: > > 000000006b6b6b6b > > Dec 11 22:47:21 dy-base R10: 0000000000000082 R11: ffff81000584d380 R12: > > ffff8100db92ad80 > > Dec 11 22:47:21 dy-base R13: ffffffff80642dc6 R14: 0000000000000000 R15: > > 0000000000000003 > > Dec 11 22:47:21 dy-base FS: 0000000000000000(0000) > > GS:ffff81011fc76b90(0000) knlGS:0000000000000000 > > Dec 11 22:47:21 dy-base CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b > > Dec 11 22:47:21 dy-base CR2: 00002ba007700000 CR3: 0000000108c05000 CR4: > > 00000000000006e0 > > Dec 11 22:47:21 dy-base Process xfslogd/3 (pid: 317, threadinfo > > ffff81011fb88000, task ffff81011fa7f830) > > Dec 11 22:47:21 dy-base Stack: > > Dec 11 22:47:21 dy-base ffff81011fb89be0 > > Dec 11 22:47:21 dy-base ffff8100db92ad80 > > Dec 11 22:47:21 dy-base 0000000000000000 > > Dec 11 22:47:21 dy-base 0000000000000000 > > Dec 11 22:47:21 dy-base > > Dec 11 22:47:21 dy-base ffff81011fb89c10 > > Dec 11 22:47:21 dy-base ffffffff803f3bdc > > Dec 11 22:47:21 dy-base 0000000000000282 > > Dec 11 22:47:21 dy-base 0000000000000000 > > Dec 11 22:47:21 dy-base > > Dec 11 22:47:21 dy-base 0000000000000000 > > Dec 11 22:47:21 dy-base 0000000000000000 > > Dec 11 22:47:21 dy-base ffff81011fb89c30 > > Dec 11 22:47:21 dy-base ffffffff805e7f2b > > Dec 11 22:47:21 dy-base > > Dec 11 22:47:21 dy-base Call Trace: > > Dec 11 22:47:21 dy-base [] _raw_spin_lock+0x23/0xf1 > > Dec 11 22:47:21 dy-base [] _spin_lock_irqsave+0x11/0x18 > > Dec 11 22:47:21 dy-base [] __wake_up+0x22/0x50 > > Dec 11 22:47:21 dy-base [] xfs_buf_unpin+0x21/0x23 > > Dec 11 22:47:21 dy-base [] xfs_buf_item_unpin+0x2e/0xa6 > > Dec 11 22:47:21 dy-base [] > > xfs_trans_chunk_committed+0xc3/0xf7 > > Dec 11 22:47:21 dy-base [] > xfs_trans_committed+0x49/0xde > > Dec 11 22:47:21 dy-base [] > > xlog_state_do_callback+0x185/0x33f > > Dec 11 22:47:21 dy-base [] xlog_iodone+0x104/0x131 > > Dec 11 22:47:22 dy-base [] > xfs_buf_iodone_work+0x1a/0x3e > > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > > Dec 11 22:47:22 dy-base [] run_workqueue+0xa8/0xf8 > > Dec 11 22:47:22 dy-base [] xfs_buf_iodone_work+0x0/0x3e > > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > > Dec 11 22:47:22 dy-base [] worker_thread+0xfb/0x134 > > Dec 11 22:47:22 dy-base [] > default_wake_function+0x0/0xf > > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > > Dec 11 22:47:22 dy-base [] kthread+0xd8/0x10b > > Dec 11 22:47:22 dy-base [] schedule_tail+0x45/0xa6 > > Dec 11 22:47:22 dy-base [] child_rip+0xa/0x12 > > Dec 11 22:47:22 dy-base [] worker_thread+0x0/0x134 > > Dec 11 22:47:22 dy-base [] kthread+0x0/0x10b > > Dec 11 22:47:22 dy-base [] child_rip+0x0/0x12 > > Dec 11 22:47:22 dy-base > > Dec 11 22:47:22 dy-base > > Dec 11 22:47:22 dy-base Code: > > Dec 11 22:47:22 dy-base 8b > > Dec 11 22:47:22 dy-base 83 > > Dec 11 22:47:22 dy-base 0c > > Dec 11 22:47:22 dy-base 01 > > Dec 11 22:47:22 dy-base 00 > > Dec 11 22:47:22 dy-base 00 > > Dec 11 22:47:22 dy-base 48 > > Dec 11 22:47:22 dy-base 8d > > Dec 11 22:47:22 dy-base 8b > > Dec 11 22:47:22 dy-base 98 > > Dec 11 22:47:22 dy-base 02 > > Dec 11 22:47:22 dy-base 00 > > Dec 11 22:47:22 dy-base 00 > > Dec 11 22:47:22 dy-base 41 > > Dec 11 22:47:22 dy-base 8b > > Dec 11 22:47:22 dy-base 54 > > Dec 11 22:47:22 dy-base 24 > > Dec 11 22:47:22 dy-base 04 > > Dec 11 22:47:22 dy-base 41 > > Dec 11 22:47:22 dy-base 89 > > Dec 11 22:47:22 dy-base > > Dec 11 22:47:22 dy-base RIP > > Dec 11 22:47:22 dy-base [] spin_bug+0x69/0xdf > > Dec 11 22:47:22 dy-base RSP > > Dec 11 22:47:22 dy-base > > Dec 11 22:47:22 dy-base Kernel panic - not syncing: Fatal exception > > Dec 11 22:47:22 dy-base > > Dec 11 22:47:22 dy-base Rebooting in 5 seconds.. > > > > After this, sometimes the server reboots normally, but sometimes hangs, no > > console, no sysreq, no nothing. > > > > This is a "simple" crash, no "too much" data lost, or else. > > > > Can somebody help me to tracking down the problem? > > > > Thanks, > > Janos Haar > > > > > > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From owner-xfs@oss.sgi.com Sat Dec 16 09:58:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 16 Dec 2006 09:58:41 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBGHwSqw011834 for ; Sat, 16 Dec 2006 09:58:32 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Gvdmr-0005MN-TV for linux-xfs@oss.sgi.com; Sat, 16 Dec 2006 18:57:29 +0100 Received: from finn.gmane.org ([80.91.229.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Dec 2006 18:57:29 +0100 Received: from mszpak by finn.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 16 Dec 2006 18:57:29 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: =?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?= Subject: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed Date: Sat, 16 Dec 2006 18:58:00 +0100 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: finn.gmane.org User-Agent: Thunderbird 1.5.0.8 (X11/20061107) X-archive-position: 10020 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mszpak@wp.pl Precedence: bulk X-list: xfs Content-Length: 1076 Lines: 29 Hi, A few weeks ago I described problem with my file system (caused by a bug in kernel 2.6.17) - http://oss.sgi.com/archives/xfs/2006-11/msg00271.html Recently I've got rescue CD with xfs_progs in version 2.8.11 and tried to repair it. xfs_repair gave me about 150 files with names like inode numbers in /lost+found and 1500 "normal" named files in its subdirectory. I've tried to use "xfs_ncheck -i inode /dev/hdX" to got names corresponding with specified inode(s), but program had been runing several minutes, xfs_db had eaten all available memory (768MB) and was killed by system (whole system hung too). The second time I killed it (kill -15) when it ate whole available memory. My file system has about 6GB and is filled with 95%. Am I doing something wrong with xfs_db? Is there any easier way to restore my files? Btw, xfs_check shows two lines: link count mismatch for inode 1572882 (name ?), nlink 16, counted 15 link count mismatch for inode 2102297 (name ?), nlink 2, counted 3 Can it be reason for strange xfs_db behavior? Thanks for help Marcin From owner-xfs@oss.sgi.com Sun Dec 17 15:58:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 17 Dec 2006 15:58:30 -0800 (PST) Received: from netcenter.hu (ns.netcenter.hu [195.228.254.57]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBHNwLqw007194 for ; Sun, 17 Dec 2006 15:58:22 -0800 Received: from dcccs (dsl5401D0F5.pool.t-online.hu [84.1.208.245]) by netcenter.hu (8.13.4/8.12.8) with SMTP id kBHNsoR3003007; Mon, 18 Dec 2006 00:54:50 +0100 Message-ID: <026501c72237$0464f7a0$0400a8c0@dcccs> From: =?iso-8859-1?Q?Haar_J=E1nos?= To: "David Chinner" Cc: , References: <003701c71d78$33ed28d0$0400a8c0@dcccs> <00ab01c71e53$942af2f0$0400a8c0@dcccs> <000d01c72127$3d7509b0$0400a8c0@dcccs> <20061217224457.GN33919298@melbourne.sgi.com> Subject: Re: xfslogd-spinlock bug? Date: Mon, 18 Dec 2006 00:56:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-archive-position: 10021 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 4751 Lines: 138 ----- Original Message ----- From: "David Chinner" To: "Haar János" Cc: ; Sent: Sunday, December 17, 2006 11:44 PM Subject: Re: xfslogd-spinlock bug? > On Sat, Dec 16, 2006 at 12:19:45PM +0100, Haar János wrote: > > Hi > > > > I have some news. > > > > I dont know there is a context between 2 messages, but i can see, the > > spinlock bug comes always on cpu #3. > > > > Somebody have any idea? > > Your disk interrupts are directed to CPU 3, and so log I/O completion > occurs on that CPU. CPU0 CPU1 CPU2 CPU3 0: 100 0 0 4583704 IO-APIC-edge timer 1: 0 0 0 2 IO-APIC-edge i8042 4: 0 0 0 3878668 IO-APIC-edge serial 8: 0 0 0 0 IO-APIC-edge rtc 9: 0 0 0 0 IO-APIC-fasteoi acpi 12: 0 0 0 3 IO-APIC-edge i8042 14: 3072118 0 0 181 IO-APIC-edge ide0 16: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb2 18: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 0 0 0 0 IO-APIC-fasteoi uhci_hcd:usb3 23: 0 0 0 0 IO-APIC-fasteoi ehci_hcd:usb1 52: 0 0 0 213052723 IO-APIC-fasteoi eth1 53: 0 0 0 91913759 IO-APIC-fasteoi eth2 100: 0 0 0 16776910 IO-APIC-fasteoi eth0 NMI: 42271 43187 42234 43168 LOC: 4584247 4584219 4584215 4584198 ERR: 0 Maybe.... I have 3 XFS on this system, with 3 source. 1. 200G one ide hdd. 2. 2x200G mirror on 1 ide + 1 sata hdd. 3. 4x3.3TB strip on NBD. The NBD serves through eth1, and it is on the CPU3, but the ide0 is on the CPU0. > > > Dec 16 12:08:36 dy-base BUG: spinlock bad magic on CPU#3, xfslogd/3/317 > > Dec 16 12:08:36 dy-base general protection fault: 0000 [1] > > Dec 16 12:08:36 dy-base SMP > > Dec 16 12:08:36 dy-base > > Dec 16 12:08:36 dy-base CPU 3 > > Dec 16 12:08:36 dy-base > > Dec 16 12:08:36 dy-base Modules linked in: > > Dec 16 12:08:36 dy-base nbd > > Are you using XFS on a NBD? Yes, on the 3. source. I used it about 1.5 years. (The nbd deadlock is fixed on my system, thanks to Herbert Xu on 2.6.14.) > > > Dec 16 12:08:36 dy-base rd > > Dec 16 12:08:36 dy-base netconsole > > Dec 16 12:08:36 dy-base e1000 > > Dec 16 12:08:36 dy-base video > > Dec 16 12:08:36 dy-base > > Dec 16 12:08:36 dy-base Pid: 317, comm: xfslogd/3 Not tainted 2.6.19 #1 > > Dec 16 12:08:36 dy-base RIP: 0010:[] > > Dec 16 12:08:36 dy-base [] spin_bug+0x69/0xdf > > Dec 16 12:08:36 dy-base RSP: 0018:ffff81011fdedbc0 EFLAGS: 00010002 > > Dec 16 12:08:36 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: > ^^^^^^^^^^^^^^^^ > Anyone recognise that pattern? I think i have one idea. This issue can stops sometimes the 5sec automatic restart on crash, and this shows possible memory corruption, and if the bug occurs in the IRQ handling.... :-) I have a lot of logs about this issue, and the RAX, RBX always the same. > > > Dec 16 12:08:36 dy-base Call Trace: > > Dec 16 12:08:36 dy-base [] _raw_spin_lock+0x23/0xf1 > > Dec 16 12:08:36 dy-base [] _spin_lock_irqsave+0x11/0x18 > > Dec 16 12:08:36 dy-base [] __wake_up+0x22/0x50 > > Dec 16 12:08:36 dy-base [] xfs_buf_unpin+0x21/0x23 > > Dec 16 12:08:36 dy-base [] xfs_buf_item_unpin+0x2e/0xa6 > > This implies a spinlock inside a wait_queue_head_t is corrupt. > > What are you type of system do you have, and what sort of > workload are you running? OS: Fedora 5, 64bit. HW: dual xeon, with HT, ram 4GB. (the min_free_kbytes limit is set to 128000, because sometimes the e1000 driver run out the reserved memory during irq handling.) Workload: I use this system for free web storage. (2x apache 2.0.xx, 12x pure-ftpd, 2x mysql but sql only use the source #2 fs.) The normal system load is ~20-40, but currently i have a little problem with apache, because it sometimes starts to read a lot from the big XFS device, and eats all memory, the load is rising to 700-800. At this point i use httpd restart, and everithing go back to normal, but if i offline..... Thanks a lot! Janos > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group From owner-xfs@oss.sgi.com Sun Dec 17 16:59:19 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 17 Dec 2006 16:59:27 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBI0xGqw018038 for ; Sun, 17 Dec 2006 16:59:17 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA20709; Mon, 18 Dec 2006 11:58:19 +1100 Message-Id: <200612180058.LAA20709@larry.melbourne.sgi.com> From: "Barry Naujok" To: "'Rainer Krienke'" , Subject: RE: LEAFN node level is 1 warning in xfs_repair Date: Mon, 18 Dec 2006 12:04:09 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200612151136.47182.krienke@uni-koblenz.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccgOT4Sj/v3sHKcRNeH31plNg5YNwCBsGLg X-archive-position: 10022 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1012 Lines: 37 > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Rainer Krienke > Sent: Friday, 15 December 2006 9:37 PM > To: xfs@oss.sgi.com > Subject: LEAFN node level is 1 warning in xfs_repair > > Hello, > > I have a xfs filesystem on a SuSE SLES10 (kernel 2.6.16.21) > system that was > created just a week ago. Because I wanted to know how long it > might take to > run xfs_repair in case it might be needed I started > xfs_repair on it without > that I thought I would actually need it. > > Now for several inodes xfs_repair reports in Phase 3 and 4 > > LEAFN node level is 1 > > warning. In the mailinglists I found that other people have the same > experience. > > The question is, if this warning anything serious that might > lead into a > filesystem corruption later. Or can I just forget about this warning? It is a bogus warning that has been fixed in xfsprogs 2.8.15 and later. You can forget about the warning. Regards, Barry. From owner-xfs@oss.sgi.com Sun Dec 17 17:31:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 17 Dec 2006 17:32:04 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBI1Vrqw021575 for ; Sun, 17 Dec 2006 17:31:55 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA21311; Mon, 18 Dec 2006 12:18:24 +1100 Message-Id: <200612180118.MAA21311@larry.melbourne.sgi.com> From: "Barry Naujok" To: "=?iso-8859-2?Q?'Marcin_Zaj=B1czkowski'?=" , Subject: RE: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed Date: Mon, 18 Dec 2006 12:24:21 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcchO+Hkj6O0EbHPTqSusDHkZwevMgBBXi3g X-archive-position: 10023 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 2169 Lines: 59 > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Marcin Zajaczkowski > Sent: Sunday, 17 December 2006 4:58 AM > To: linux-xfs@oss.sgi.com > Subject: xfs_ncheck (actually xfs_db) eats a lot of memory > and is killed > > Hi, > > > A few weeks ago I described problem with my file system > (caused by a bug > in kernel 2.6.17) - > http://oss.sgi.com/archives/xfs/2006-11/msg00271.html > > Recently I've got rescue CD with xfs_progs in version 2.8.11 > and tried > to repair it. xfs_repair gave me about 150 files with names > like inode > numbers in /lost+found and 1500 "normal" named files in its > subdirectory. > I've tried to use "xfs_ncheck -i inode /dev/hdX" to got names > corresponding with specified inode(s), but program had been runing > several minutes, xfs_db had eaten all available memory > (768MB) and was > killed by system (whole system hung too). The second time I killed it > (kill -15) when it ate whole available memory. > My file system has about 6GB and is filled with 95%. This is the second report of a smallish filesystem using all of the system's memory (the other being xfs_repair). Hopefully when I diagnose the problem with the previous report, I can fix the same issue with xfs_db and your filesystem. If it at all possible, can you xfs_copy the offending filesystem to a file and compress it and make it available to me to find/fix the problem. > Am I doing something wrong with xfs_db? > Is there any easier way to restore my files? Your files have been restored as much as possible. You'll have to work out what is in lost+found and move them back to their appropriate locations. > Btw, xfs_check shows two lines: > link count mismatch for inode 1572882 (name ?), nlink 16, counted 15 > link count mismatch for inode 2102297 (name ?), nlink 2, counted 3 > Can it be reason for strange xfs_db behavior? No, this shouldn't be causing the xfs_db strange behaviour, but the nlink count mismatch is a problem with xfs_repair 2.8.11. Try and use xfs_repair 2.8.16 and later to fix this issue. Older versions before 2.8.11 will also fix the nlink issue. From owner-xfs@oss.sgi.com Sun Dec 17 22:46:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 17 Dec 2006 22:47:02 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBI6krqw024069 for ; Sun, 17 Dec 2006 22:46:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA28336; Mon, 18 Dec 2006 17:24:50 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBI6Om7Y59760831; Mon, 18 Dec 2006 17:24:48 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBI6Oi2Z64560635; Mon, 18 Dec 2006 17:24:44 +1100 (AEDT) Date: Mon, 18 Dec 2006 17:24:44 +1100 From: David Chinner To: Haar =?iso-8859-1?Q?J=E1nos?= Cc: David Chinner , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: xfslogd-spinlock bug? Message-ID: <20061218062444.GH44411608@melbourne.sgi.com> References: <003701c71d78$33ed28d0$0400a8c0@dcccs> <00ab01c71e53$942af2f0$0400a8c0@dcccs> <000d01c72127$3d7509b0$0400a8c0@dcccs> <20061217224457.GN33919298@melbourne.sgi.com> <026501c72237$0464f7a0$0400a8c0@dcccs> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <026501c72237$0464f7a0$0400a8c0@dcccs> User-Agent: Mutt/1.4.2.1i X-archive-position: 10026 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2765 Lines: 77 On Mon, Dec 18, 2006 at 12:56:41AM +0100, Haar János wrote: > > On Sat, Dec 16, 2006 at 12:19:45PM +0100, Haar János wrote: > > > I dont know there is a context between 2 messages, but i can see, the > > > spinlock bug comes always on cpu #3. > > > > > > Somebody have any idea? > > > > Your disk interrupts are directed to CPU 3, and so log I/O completion > > occurs on that CPU. > > CPU0 CPU1 CPU2 CPU3 > 0: 100 0 0 4583704 IO-APIC-edge timer > 1: 0 0 0 2 IO-APIC-edge i8042 > 4: 0 0 0 3878668 IO-APIC-edge serial ..... > 14: 3072118 0 0 181 IO-APIC-edge ide0 ..... > 52: 0 0 0 213052723 IO-APIC-fasteoi eth1 > 53: 0 0 0 91913759 IO-APIC-fasteoi eth2 > 100: 0 0 0 16776910 IO-APIC-fasteoi eth0 .... > > Maybe.... > I have 3 XFS on this system, with 3 source. > > 1. 200G one ide hdd. > 2. 2x200G mirror on 1 ide + 1 sata hdd. > 3. 4x3.3TB strip on NBD. > > The NBD serves through eth1, and it is on the CPU3, but the ide0 is on the > CPU0. I'd say your NBD based XFS filesystem is having trouble. > > Are you using XFS on a NBD? > > Yes, on the 3. source. Ok, I've never heard of a problem like this before and you are doing something that very few ppl are doing (i.e. XFS on NBD). I'd start Hence I'd start by suspecting a bug in the NBD driver. > > > Dec 16 12:08:36 dy-base RSP: 0018:ffff81011fdedbc0 EFLAGS: 00010002 > > > Dec 16 12:08:36 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: > > ^^^^^^^^^^^^^^^^ > > Anyone recognise that pattern? > > I think i have one idea. > This issue can stops sometimes the 5sec automatic restart on crash, and this > shows possible memory corruption, and if the bug occurs in the IRQ > handling.... :-) > I have a lot of logs about this issue, and the RAX, RBX always the same. And is this the only place where you see the problem? Or are there other stack traces that you see this in as well? > > This implies a spinlock inside a wait_queue_head_t is corrupt. > > > > What are you type of system do you have, and what sort of > > workload are you running? > > OS: Fedora 5, 64bit. > HW: dual xeon, with HT, ram 4GB. > (the min_free_kbytes limit is set to 128000, because sometimes the e1000 > driver run out the reserved memory during irq handling.) That does not sound good. What happens when it does run out of memory? Is that when you start to see the above corruptions? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 18 00:16:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 00:16:57 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBI8Gkqw001765 for ; Mon, 18 Dec 2006 00:16:49 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GwDeG-0001GH-PM for linux-xfs@oss.sgi.com; Mon, 18 Dec 2006 09:15:01 +0100 Received: from finn.gmane.org ([80.91.229.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Dec 2006 09:15:00 +0100 Received: from mszpak by finn.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Dec 2006 09:15:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: =?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?= Subject: Re: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed Date: Mon, 18 Dec 2006 09:15:19 +0100 Message-ID: References: <200612180118.MAA21311@larry.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: finn.gmane.org User-Agent: Thunderbird 1.5.0.8 (X11/20061107) In-Reply-To: <200612180118.MAA21311@larry.melbourne.sgi.com> X-archive-position: 10027 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mszpak@wp.pl Precedence: bulk X-list: xfs Content-Length: 2603 Lines: 64 Barry Naujok wrote: >> Subject: xfs_ncheck (actually xfs_db) eats a lot of memory >> and is killed (...) >> Recently I've got rescue CD with xfs_progs in version 2.8.11 >> and tried >> to repair it. xfs_repair gave me about 150 files with names >> like inode >> numbers in /lost+found and 1500 "normal" named files in its >> subdirectory. >> I've tried to use "xfs_ncheck -i inode /dev/hdX" to got names >> corresponding with specified inode(s), but program had been runing >> several minutes, xfs_db had eaten all available memory >> (768MB) and was >> killed by system (whole system hung too). The second time I killed it >> (kill -15) when it ate whole available memory. >> My file system has about 6GB and is filled with 95%. > > This is the second report of a smallish filesystem using all of the > system's memory (the other being xfs_repair). Hopefully when I diagnose > the problem with the previous report, I can fix the same issue with > xfs_db and your filesystem. > > If it at all possible, can you xfs_copy the offending filesystem to a > file and compress it and make it available to me to find/fix the > problem. Hmm, it won't be so easy. Compressed dump of a fielsystem before repair (I had to use dd, because xfsdump refused to cooperate) has 2,5GB. Damaged files were (probably) only in one directory /usr/bin. Maybe I could reduce size of the image excluding few other directories (in xfsdump)? Do you think that error would still occur? >> Am I doing something wrong with xfs_db? >> Is there any easier way to restore my files? > > Your files have been restored as much as possible. You'll have to work > out what is in lost+found and move them back to their appropriate > locations. With files with "normal" names there is no problem. There are all from one directory (/usr/bin), but I'm unable (without xfs_ncheck) to map files with inode-like names with their normal names (150+ files). I tried with xfs_db and the way described in your FAQ, but I had some problems too. >> Btw, xfs_check shows two lines: >> link count mismatch for inode 1572882 (name ?), nlink 16, counted 15 >> link count mismatch for inode 2102297 (name ?), nlink 2, counted 3 >> Can it be reason for strange xfs_db behavior? > > No, this shouldn't be causing the xfs_db strange behaviour, but the > nlink count mismatch is a problem with xfs_repair 2.8.11. Try and use > xfs_repair 2.8.16 and later to fix this issue. Older versions before > 2.8.11 will also fix the nlink issue. I have some old system rescue CD with xfs_progs from line 2.7.x. Would it be ok? Regards Marcin From owner-xfs@oss.sgi.com Mon Dec 18 00:19:45 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 00:19:52 -0800 (PST) Received: from netcenter.hu (ns.netcenter.hu [195.228.254.57]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBI8Jgqw006783 for ; Mon, 18 Dec 2006 00:19:44 -0800 Received: from dcccs (dsl5401D0F5.pool.t-online.hu [84.1.208.245]) by netcenter.hu (8.13.4/8.12.8) with SMTP id kBI8GBOq017804; Mon, 18 Dec 2006 09:16:11 +0100 Message-ID: <027b01c7227d$0e26d1f0$0400a8c0@dcccs> From: =?iso-8859-1?Q?Haar_J=E1nos?= To: "David Chinner" Cc: , , References: <003701c71d78$33ed28d0$0400a8c0@dcccs> <00ab01c71e53$942af2f0$0400a8c0@dcccs> <000d01c72127$3d7509b0$0400a8c0@dcccs> <20061217224457.GN33919298@melbourne.sgi.com> <026501c72237$0464f7a0$0400a8c0@dcccs> <20061218062444.GH44411608@melbourne.sgi.com> Subject: Re: xfslogd-spinlock bug? Date: Mon, 18 Dec 2006 09:17:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-archive-position: 10028 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 7342 Lines: 201 ----- Original Message ----- From: "David Chinner" To: "Haar János" Cc: "David Chinner" ; ; Sent: Monday, December 18, 2006 7:24 AM Subject: Re: xfslogd-spinlock bug? > On Mon, Dec 18, 2006 at 12:56:41AM +0100, Haar János wrote: > > > On Sat, Dec 16, 2006 at 12:19:45PM +0100, Haar János wrote: > > > > I dont know there is a context between 2 messages, but i can see, the > > > > spinlock bug comes always on cpu #3. > > > > > > > > Somebody have any idea? > > > > > > Your disk interrupts are directed to CPU 3, and so log I/O completion > > > occurs on that CPU. > > > > CPU0 CPU1 CPU2 CPU3 > > 0: 100 0 0 4583704 IO-APIC-edge timer > > 1: 0 0 0 2 IO-APIC-edge i8042 > > 4: 0 0 0 3878668 IO-APIC-edge serial > ..... > > 14: 3072118 0 0 181 IO-APIC-edge ide0 > ..... > > 52: 0 0 0 213052723 IO-APIC-fasteoi eth1 > > 53: 0 0 0 91913759 IO-APIC-fasteoi eth2 > > 100: 0 0 0 16776910 IO-APIC-fasteoi eth0 > .... > > > > Maybe.... > > I have 3 XFS on this system, with 3 source. > > > > 1. 200G one ide hdd. > > 2. 2x200G mirror on 1 ide + 1 sata hdd. > > 3. 4x3.3TB strip on NBD. > > > > The NBD serves through eth1, and it is on the CPU3, but the ide0 is on the > > CPU0. > > I'd say your NBD based XFS filesystem is having trouble. > > > > Are you using XFS on a NBD? > > > > Yes, on the 3. source. > > Ok, I've never heard of a problem like this before and you are doing > something that very few ppl are doing (i.e. XFS on NBD). I'd start > Hence I'd start by suspecting a bug in the NBD driver. Ok, if you have right, this also can be in context with the following issue: http://download.netcenter.hu/bughunt/20061217/messages.txt (10KB) > > > > > Dec 16 12:08:36 dy-base RSP: 0018:ffff81011fdedbc0 EFLAGS: 00010002 > > > > Dec 16 12:08:36 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: > > > ^^^^^^^^^^^^^^^^ > > > Anyone recognise that pattern? > > > > I think i have one idea. > > This issue can stops sometimes the 5sec automatic restart on crash, and this > > shows possible memory corruption, and if the bug occurs in the IRQ > > handling.... :-) > > I have a lot of logs about this issue, and the RAX, RBX always the same. > > And is this the only place where you see the problem? Or are there > other stack traces that you see this in as well? I have used the 2.6.16.18 for a long time, and it was stable, except this issue. (~20 dump with xfslogd) And i try the new releases, and now i have more. :-) What do you think exactly? I can see in the logs, but search for what? The RAX, RBX thing, or the xfslogd-spinlock problem or the old nbd-deadlock + mem corruption? [root@NetCenter netlog]# grep "0000000000000033" messages* messages.1:Dec 11 22:47:21 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.1:Dec 12 18:16:35 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.1:Dec 13 11:40:05 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.1:Dec 14 22:25:32 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.1:Dec 15 06:24:44 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.1:Dec 16 12:08:36 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.11:Oct 3 19:49:44 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.11:Oct 7 01:11:17 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.13:Sep 21 15:35:31 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.15:Sep 3 16:13:35 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.15:Sep 5 21:00:38 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.2:Dec 9 00:10:47 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.2:Dec 9 14:07:01 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.2:Dec 10 04:44:48 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.3:Nov 30 10:59:21 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.3:Dec 2 00:54:23 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.5:Nov 13 10:44:49 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.5:Nov 14 03:14:14 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.5:Nov 14 03:37:07 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.5:Nov 15 01:39:54 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.6:Nov 6 14:48:54 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.6:Nov 7 04:36:13 dy-base RAX: 0000000000000033 RBX: ffff8100057d2080 RCX: ffff810050d638f8 messages.6:Nov 7 04:36:13 dy-base RDX: 0000000000000008 RSI: 0000000000012cff RDI: 0000000000000033 messages.6:Nov 7 11:12:06 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.6:Nov 8 03:20:38 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.6:Nov 8 15:02:16 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.6:Nov 8 15:27:12 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.6:Nov 10 15:29:43 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.6:Nov 11 20:44:14 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.9:Oct 18 15:31:02 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 messages.9:Oct 19 13:53:24 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: 0000000000000000 > > > > This implies a spinlock inside a wait_queue_head_t is corrupt. > > > > > > What are you type of system do you have, and what sort of > > > workload are you running? > > > > OS: Fedora 5, 64bit. > > HW: dual xeon, with HT, ram 4GB. > > (the min_free_kbytes limit is set to 128000, because sometimes the e1000 > > driver run out the reserved memory during irq handling.) > > That does not sound good. What happens when it does run out of memory? This is an old problem, on 2.6.16.18 . The default min_free_kbytes is 38xx , and the GIGE controller easily can be overflow this little place. If this happens, the system freez, and i can only use the serial console + sysreq to dump stack: download.netcenter.hu/bughunt/20060530/261618-good.txt download.netcenter.hu/bughunt/20060530/dmesg.txt download.netcenter.hu/bughunt/20060530/dump.txt This problem is already fixed with set the min_free_kbytes to 128M. > Is that when you start to see the above corruptions? I think no, but i am not 100% sure. Cheers, Janos > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 18 05:23:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 05:23:52 -0800 (PST) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBIDNdqw016665 for ; Mon, 18 Dec 2006 05:23:43 -0800 Received: from localhost ([192.168.0.78]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id kBIDMXeA025726; Mon, 18 Dec 2006 16:22:35 +0300 (MSK) To: linux-kernel@vger.kernel.org CC: , Andrew Morton , xfs@oss.sgi.com Subject: [PATCH] incorrect direct io error handling From: Dmitriy Monakhov Date: Mon, 18 Dec 2006 16:22:44 +0300 Message-ID: <87d56he3tn.fsf@sw.ru> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-archive-position: 10029 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dmonakhov@openvz.org Precedence: bulk X-list: xfs Content-Length: 4288 Lines: 109 --=-=-= This patch is result of discussion started week ago here: http://lkml.org/lkml/2006/12/11/66 changes from original patch: - Update wrong comments about i_mutex locking. - Add BUG_ON(!mutex_is_locked(..)) for non blkdev. - vmtruncate call only for non blockdev LOG: If generic_file_direct_write() has fail (ENOSPC condition) inside __generic_file_aio_write_nolock() it may have instantiated a few blocks outside i_size. And fsck will complain about wrong i_size (ext2, ext3 and reiserfs interpret i_size and biggest block difference as error), after fsck will fix error i_size will be increased to the biggest block, but this blocks contain gurbage from previous write attempt, this is not information leak, but its silence file data corruption. This issue affect fs regardless the values of blocksize or pagesize. We need truncate any block beyond i_size after write have failed , do in simular generic_file_buffered_write() error path. If host is !S_ISBLK i_mutex always held inside generic_file_aio_write_nolock() and we may safely call vmtruncate(). Some fs (XFS at least) may directly call generic_file_direct_write()with i_mutex not held. There is no general scenario in this case. This fs have to handle generic_file_direct_write() error by its own specific way (place). Issue was found during OpenVZ kernel testing. Exampe: open("mnt2/FILE3", O_WRONLY|O_CREAT|O_DIRECT, 0666) = 3 write(3, "aaaaaa"..., 4096) = -1 ENOSPC (No space left on device) stat mnt2/FILE3 File: `mnt2/FILE3' Size: 0 Blocks: 4 IO Block: 4096 regular empty file >>>>>>>>>>>>>>>>>>>>>>^^^^^^^^^^ file size is less than biggest block idx Device: 700h/1792d Inode: 14 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) fsck.ext2 -f -n mnt1/fs_img Pass 1: Checking inodes, blocks, and sizes Inode 14, i_size is 0, should be 2048. Fix? no Signed-off-by: Dmitriy Monakhov ------------- --=-=-= Content-Disposition: inline; filename=direct-io-fix.patch2 diff --git a/mm/filemap.c b/mm/filemap.c index 8332c77..7c571dd 100644 --- a/mm/filemap.c +++ b/mm/filemap.c @@ -2044,8 +2044,9 @@ generic_file_direct_write(struct kiocb * /* * Sync the fs metadata but not the minor inode changes and * of course not the data as we did direct DMA for the IO. - * i_mutex is held, which protects generic_osync_inode() from - * livelocking. AIO O_DIRECT ops attempt to sync metadata here. + * i_mutex may not being held (XFS does this), if so some specific locking + * ordering must protect generic_osync_inode() from livelocking. + * AIO O_DIRECT ops attempt to sync metadata here. */ if ((written >= 0 || written == -EIOCBQUEUED) && ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { @@ -2279,6 +2280,17 @@ __generic_file_aio_write_nolock(struct k written = generic_file_direct_write(iocb, iov, &nr_segs, pos, ppos, count, ocount); + /* + * If host is not S_ISBLK generic_file_direct_write() may + * have instantiated a few blocks outside i_size files + * Trim these off again. + */ + if (unlikely(written < 0) && !S_ISBLK(inode->i_mode)) { + loff_t isize = i_size_read(inode); + if (pos + count > isize) + vmtruncate(inode, isize); + } + if (written < 0 || written == count) goto out; /* @@ -2341,6 +2353,13 @@ ssize_t generic_file_aio_write_nolock(st ssize_t ret; BUG_ON(iocb->ki_pos != pos); + /* + * generic_file_buffered_write() may be called inside + * __generic_file_aio_write_nolock() even in case of + * O_DIRECT for non S_ISBLK files. So i_mutex must be held. + */ + if (!S_ISBLK(inode->i_mode)) + BUG_ON(!mutex_is_locked(&inode->i_mutex)); ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, &iocb->ki_pos); @@ -2383,8 +2402,8 @@ ssize_t generic_file_aio_write(struct ki EXPORT_SYMBOL(generic_file_aio_write); /* - * Called under i_mutex for writes to S_ISREG files. Returns -EIO if something - * went wrong during pagecache shootdown. + * May be called without i_mutex for writes to S_ISREG files. XFS does this. + * Returns -EIO if something went wrong during pagecache shootdown. */ static ssize_t generic_file_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov, --=-=-=-- From owner-xfs@oss.sgi.com Mon Dec 18 12:29:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 12:29:28 -0800 (PST) Received: from mga01.intel.com ([192.55.52.88]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBIKTLqw009674 for ; Mon, 18 Dec 2006 12:29:21 -0800 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 18 Dec 2006 11:56:36 -0800 Received: from kwchen-mobl1.amr.corp.intel.com (HELO kwchenmobl1) ([10.3.52.232]) by fmsmga001.fm.intel.com with ESMTP; 18 Dec 2006 11:56:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,185,1165219200"; d="scan'208"; a="179019342:sNHT18744957" From: "Chen, Kenneth W" To: "'Dmitriy Monakhov'" , Cc: , "Andrew Morton" , Subject: RE: [PATCH] incorrect direct io error handling Date: Mon, 18 Dec 2006 11:56:36 -0800 Message-ID: <000101c722de$9fdca4b0$e834030a@amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AccireomkU5q+2FZTSmiIVVKTJhrWQAL8ZqQ In-Reply-To: <87d56he3tn.fsf@sw.ru> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-archive-position: 10031 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kenneth.w.chen@intel.com Precedence: bulk X-list: xfs Content-Length: 1531 Lines: 27 Dmitriy Monakhov wrote on Monday, December 18, 2006 5:23 AM > This patch is result of discussion started week ago here: > http://lkml.org/lkml/2006/12/11/66 > changes from original patch: > - Update wrong comments about i_mutex locking. > - Add BUG_ON(!mutex_is_locked(..)) for non blkdev. > - vmtruncate call only for non blockdev > LOG: > If generic_file_direct_write() has fail (ENOSPC condition) inside > __generic_file_aio_write_nolock() it may have instantiated > a few blocks outside i_size. And fsck will complain about wrong i_size > (ext2, ext3 and reiserfs interpret i_size and biggest block difference as error), > after fsck will fix error i_size will be increased to the biggest block, > but this blocks contain gurbage from previous write attempt, this is not > information leak, but its silence file data corruption. This issue affect > fs regardless the values of blocksize or pagesize. > We need truncate any block beyond i_size after write have failed , do in simular > generic_file_buffered_write() error path. If host is !S_ISBLK i_mutex always > held inside generic_file_aio_write_nolock() and we may safely call vmtruncate(). > Some fs (XFS at least) may directly call generic_file_direct_write()with > i_mutex not held. There is no general scenario in this case. This fs have to > handle generic_file_direct_write() error by its own specific way (place). I'm puzzled that if ext2 is able to instantiate some blocks, then why does it return no space error? Where is the error coming from? From owner-xfs@oss.sgi.com Mon Dec 18 14:16:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 14:16:22 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBIMGDqw021667 for ; Mon, 18 Dec 2006 14:16:16 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA20623; Tue, 19 Dec 2006 09:15:19 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBIMFH7Y64866347; Tue, 19 Dec 2006 09:15:17 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBIMFFFx66531807; Tue, 19 Dec 2006 09:15:15 +1100 (AEDT) Date: Tue, 19 Dec 2006 09:15:15 +1100 From: David Chinner To: Dmitriy Monakhov Cc: linux-kernel@vger.kernel.org, devel@openvz.org, Andrew Morton , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect direct io error handling Message-ID: <20061218221515.GN44411608@melbourne.sgi.com> References: <87d56he3tn.fsf@sw.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d56he3tn.fsf@sw.ru> User-Agent: Mutt/1.4.2.1i X-archive-position: 10032 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 3000 Lines: 83 On Mon, Dec 18, 2006 at 04:22:44PM +0300, Dmitriy Monakhov wrote: > diff --git a/mm/filemap.c b/mm/filemap.c > index 8332c77..7c571dd 100644 > --- a/mm/filemap.c > +++ b/mm/filemap.c > @@ -2044,8 +2044,9 @@ generic_file_direct_write(struct kiocb * > /* > * Sync the fs metadata but not the minor inode changes and > * of course not the data as we did direct DMA for the IO. > - * i_mutex is held, which protects generic_osync_inode() from > - * livelocking. AIO O_DIRECT ops attempt to sync metadata here. > + * i_mutex may not being held (XFS does this), if so some specific locking > + * ordering must protect generic_osync_inode() from livelocking. > + * AIO O_DIRECT ops attempt to sync metadata here. > */ > if ((written >= 0 || written == -EIOCBQUEUED) && > ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { > @@ -2279,6 +2280,17 @@ __generic_file_aio_write_nolock(struct k > > written = generic_file_direct_write(iocb, iov, &nr_segs, pos, > ppos, count, ocount); > + /* > + * If host is not S_ISBLK generic_file_direct_write() may > + * have instantiated a few blocks outside i_size files > + * Trim these off again. > + */ > + if (unlikely(written < 0) && !S_ISBLK(inode->i_mode)) { > + loff_t isize = i_size_read(inode); > + if (pos + count > isize) > + vmtruncate(inode, isize); > + } > + > if (written < 0 || written == count) > goto out; You comment in the first hunk that i_mutex may not be held here, but there's no comment in __generic_file_aio_write_nolock() that the i_mutex must be held for !S_ISBLK devices. > @@ -2341,6 +2353,13 @@ ssize_t generic_file_aio_write_nolock(st > ssize_t ret; > > BUG_ON(iocb->ki_pos != pos); > + /* > + * generic_file_buffered_write() may be called inside > + * __generic_file_aio_write_nolock() even in case of > + * O_DIRECT for non S_ISBLK files. So i_mutex must be held. > + */ > + if (!S_ISBLK(inode->i_mode)) > + BUG_ON(!mutex_is_locked(&inode->i_mutex)); > > ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, > &iocb->ki_pos); I note that you comment here in generic_file_aio_write_nolock(), but it's not immediately obvious that this is refering to the vmtruncate() call in __generic_file_aio_write_nolock(). IOWs, wouldn't it be better to put this comment and check in __generic_file_aio_write_nolock() directly above the vmtruncate() call that cares about this? > @@ -2383,8 +2402,8 @@ ssize_t generic_file_aio_write(struct ki > EXPORT_SYMBOL(generic_file_aio_write); > > /* > - * Called under i_mutex for writes to S_ISREG files. Returns -EIO if something > - * went wrong during pagecache shootdown. > + * May be called without i_mutex for writes to S_ISREG files. XFS does this. > + * Returns -EIO if something went wrong during pagecache shootdown. > */ Not sure you need to say "XFS does this" - other filesystems may do this in the future..... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 18 14:37:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 14:37:43 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBIMbaqw024131 for ; Mon, 18 Dec 2006 14:37:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA21336; Tue, 19 Dec 2006 09:36:41 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBIMae7Y66552415; Tue, 19 Dec 2006 09:36:40 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBIMabpm65934946; Tue, 19 Dec 2006 09:36:37 +1100 (AEDT) Date: Tue, 19 Dec 2006 09:36:37 +1100 From: David Chinner To: Haar =?iso-8859-1?Q?J=E1nos?= Cc: David Chinner , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: xfslogd-spinlock bug? Message-ID: <20061218223637.GP44411608@melbourne.sgi.com> References: <003701c71d78$33ed28d0$0400a8c0@dcccs> <00ab01c71e53$942af2f0$0400a8c0@dcccs> <000d01c72127$3d7509b0$0400a8c0@dcccs> <20061217224457.GN33919298@melbourne.sgi.com> <026501c72237$0464f7a0$0400a8c0@dcccs> <20061218062444.GH44411608@melbourne.sgi.com> <027b01c7227d$0e26d1f0$0400a8c0@dcccs> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <027b01c7227d$0e26d1f0$0400a8c0@dcccs> User-Agent: Mutt/1.4.2.1i X-archive-position: 10033 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1502 Lines: 49 On Mon, Dec 18, 2006 at 09:17:50AM +0100, Haar János wrote: > From: "David Chinner" > > > The NBD serves through eth1, and it is on the CPU3, but the ide0 is on > the > > > CPU0. > > > > I'd say your NBD based XFS filesystem is having trouble. > > > > > > Are you using XFS on a NBD? > > > > > > Yes, on the 3. source. > > > > Ok, I've never heard of a problem like this before and you are doing > > something that very few ppl are doing (i.e. XFS on NBD). I'd start > > Hence I'd start by suspecting a bug in the NBD driver. > > Ok, if you have right, this also can be in context with the following issue: > > http://download.netcenter.hu/bughunt/20061217/messages.txt (10KB) Which appears to be a crash in wake_up_process() when doing memory reclaim (waking the xfsbufd). > > > > > Dec 16 12:08:36 dy-base RSP: 0018:ffff81011fdedbc0 EFLAGS: 00010002 > > > > > Dec 16 12:08:36 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b > RCX: > > > > ^^^^^^^^^^^^^^^^ > > > > Anyone recognise that pattern? Ok, I've found this pattern: #define POISON_FREE 0x6b Can you confirm that you are running with CONFIG_DEBUG_SLAB=y? If so, we have a use after free occurring here and it would also explain why no-one has reported it before. FWIW, can you turn on CONFIG_XFS_DEBUG=y and see if that triggers a different bug check prior to the above dump? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 18 15:34:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 15:34:21 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBINYDqw029941 for ; Mon, 18 Dec 2006 15:34:15 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22434; Tue, 19 Dec 2006 10:17:02 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBINH17Y66572307; Tue, 19 Dec 2006 10:17:01 +1100 (AEDT) Received: (from allanr@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBINH1FZ66570784; Tue, 19 Dec 2006 10:17:01 +1100 (AEDT) Date: Tue, 19 Dec 2006 10:17:01 +1100 (AEDT) From: Allan Randall Message-Id: <200612182317.kBINH1FZ66570784@snort.melbourne.sgi.com> To: asg-qa@melbourne.sgi.com, allanr@melbourne.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 958893 - Integrate existing dmapi qa tests into xfs qa infrastructure X-archive-position: 10034 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: allanr@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 2744 Lines: 80 Integrate existing dmapi qa tests into xfs qa infrastructure Date: Tue Dec 19 10:16:15 AEDT 2006 Workarea: snort.melbourne.sgi.com:/home/allanr/isms/xfs-cmds-2 Inspected by: vapo The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:27764a xfstests/142 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/142 - Dmapi get/set_dmattr xfstests/142.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/142.out - Dmapi get/set_dmattr golden output xfstests/143 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/143 - Dmapi get/set_eventlist xfstests/143.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/143.out - Dmapi get/set_eventlist golden output xfstests/144 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/144 - Dmapi get/set_fileattr, get_bulkattr, get_dirattrs xfstests/144.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/144.out - Dmapi get/set_fileattr, get_bulkattr, get_dirattrs golden output xfstests/145 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/145 - Dmapi probe/punch_hole xfstests/145.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/145.out - Dmapi probe/punch_hole golden output xfstests/146 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/146 - Dmapi read/write_invis xfstests/146.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/146.out - Dmapi read/write_invis golden output xfstests/147 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/147 - Dmapi get/set_region xfstests/147.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/147.out - Dmapi get/set_region golden output xfstests/common.dmapi - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/common.dmapi - common dmapi functions xfstests/common.rc - 1.62 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/common.rc.diff?r1=text&tr1=1.62&r2=text&tr2=1.61&f=h - added filter to set dmapi's mtpt to correct mount point in _mount xfstests/Makefile - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/Makefile.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - added dmapi to makefile subdirs xfstests/group - 1.97 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/group.diff?r1=text&tr1=1.97&r2=text&tr2=1.96&f=h - added tests 142-147 xfstests/include/buildmacros - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/include/buildmacros.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h - added dmapi commands for building dmapi subdir From owner-xfs@oss.sgi.com Mon Dec 18 15:41:52 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 15:41:57 -0800 (PST) Received: from netcenter.hu (ns.netcenter.hu [195.228.254.57]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBINfmqw031167 for ; Mon, 18 Dec 2006 15:41:52 -0800 Received: from dcccs (dsl5401D0F5.pool.t-online.hu [84.1.208.245]) by netcenter.hu (8.13.4/8.12.8) with SMTP id kBINcHdv009235; Tue, 19 Dec 2006 00:38:17 +0100 Message-ID: <001a01c722fd$df5ca710$0400a8c0@dcccs> From: =?iso-8859-1?Q?Haar_J=E1nos?= To: "David Chinner" Cc: , , References: <003701c71d78$33ed28d0$0400a8c0@dcccs> <00ab01c71e53$942af2f0$0400a8c0@dcccs> <000d01c72127$3d7509b0$0400a8c0@dcccs> <20061217224457.GN33919298@melbourne.sgi.com> <026501c72237$0464f7a0$0400a8c0@dcccs> <20061218062444.GH44411608@melbourne.sgi.com> <027b01c7227d$0e26d1f0$0400a8c0@dcccs> <20061218223637.GP44411608@melbourne.sgi.com> Subject: Re: xfslogd-spinlock bug? Date: Tue, 19 Dec 2006 00:39:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-archive-position: 10035 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 2143 Lines: 85 ----- Original Message ----- From: "David Chinner" To: "Haar János" Cc: "David Chinner" ; ; Sent: Monday, December 18, 2006 11:36 PM Subject: Re: xfslogd-spinlock bug? > On Mon, Dec 18, 2006 at 09:17:50AM +0100, Haar János wrote: > > From: "David Chinner" > > > > The NBD serves through eth1, and it is on the CPU3, but the ide0 is on > > the > > > > CPU0. > > > > > > I'd say your NBD based XFS filesystem is having trouble. > > > > > > > > Are you using XFS on a NBD? > > > > > > > > Yes, on the 3. source. > > > > > > Ok, I've never heard of a problem like this before and you are doing > > > something that very few ppl are doing (i.e. XFS on NBD). I'd start > > > Hence I'd start by suspecting a bug in the NBD driver. > > > > Ok, if you have right, this also can be in context with the following issue: > > > > http://download.netcenter.hu/bughunt/20061217/messages.txt (10KB) > > Which appears to be a crash in wake_up_process() when doing memory > reclaim (waking the xfsbufd). Sorry, can you translate it to "poor mans language"? :-) This is a different bug? > > > > > > > Dec 16 12:08:36 dy-base RSP: 0018:ffff81011fdedbc0 EFLAGS: 00010002 > > > > > > Dec 16 12:08:36 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b > > RCX: > > > > > ^^^^^^^^^^^^^^^^ > > > > > Anyone recognise that pattern? > > Ok, I've found this pattern: > > #define POISON_FREE 0x6b > > Can you confirm that you are running with CONFIG_DEBUG_SLAB=y? Yes, i build with this option enabled. Is this wrong? > > If so, we have a use after free occurring here and it would also > explain why no-one has reported it before. > > FWIW, can you turn on CONFIG_XFS_DEBUG=y and see if that triggers > a different bug check prior to the above dump? [root@X64 linux-2.6.19]# make bzImage scripts/kconfig/conf -s arch/x86_64/Kconfig .config:7:warning: trying to assign nonexistent symbol XFS_DEBUG I have missed something? Thanks, Janos > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 18 15:50:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 15:50:21 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBINoDqw000450 for ; Mon, 18 Dec 2006 15:50:16 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23525; Tue, 19 Dec 2006 10:49:20 +1100 Message-Id: <200612182349.KAA23525@larry.melbourne.sgi.com> From: "Barry Naujok" To: "=?iso-8859-2?Q?'Marcin_Zaj=B1czkowski'?=" , Subject: RE: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed Date: Tue, 19 Dec 2006 10:54:49 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccifOn4OcIjD1s9SIKDFJ/LPnHzrwAfjWOQ X-archive-position: 10036 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 947 Lines: 31 > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Marcin Zajaczkowski > Sent: Monday, 18 December 2006 7:15 PM > To: linux-xfs@oss.sgi.com > Subject: Re: xfs_ncheck (actually xfs_db) eats a lot of > memory and is killed > > Barry Naujok wrote: > >> Btw, xfs_check shows two lines: > >> link count mismatch for inode 1572882 (name ?), nlink 16, > counted 15 > >> link count mismatch for inode 2102297 (name ?), nlink 2, counted 3 > >> Can it be reason for strange xfs_db behavior? > > > > No, this shouldn't be causing the xfs_db strange behaviour, but the > > nlink count mismatch is a problem with xfs_repair 2.8.11. > Try and use > > xfs_repair 2.8.16 and later to fix this issue. Older versions before > > 2.8.11 will also fix the nlink issue. > > I have some old system rescue CD with xfs_progs from line > 2.7.x. Would > it be ok? Yes, that should be fine AFAIK. Barry. From owner-xfs@oss.sgi.com Mon Dec 18 17:11:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 17:11:14 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBJ1B6qw014316 for ; Mon, 18 Dec 2006 17:11:07 -0800 Received: from edge (unknown [124.178.235.100]) by postoffice.aconex.com (Postfix) with ESMTP id EAC04AACA36; Tue, 19 Dec 2006 12:03:43 +1100 (EST) Subject: [PATCH] rethink removal of xattr syscall stubs (for now) From: Nathan Scott Reply-To: nscott@aconex.com To: bnaujok@sgi.com, xfs@oss.sgi.com Cc: agruen@suse.de Content-Type: multipart/mixed; boundary="=-dpJpTHodwH2NZsc/s/EW" Organization: Aconex Date: Tue, 19 Dec 2006 12:10:58 +1100 Message-Id: <1166490658.5572.89.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-archive-position: 10037 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 11379 Lines: 357 --=-dpJpTHodwH2NZsc/s/EW Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, It turns out (*cough*) that we use an export file with libattr, that I completely forgot about, which specifies the *xattr calls as part of the ATTR_1 interface. This patch reverts the syscall stub removal patch from before, includes Lennerts patch to fix the original problem ARM EABI, and I'll go think some more about how to properly fix this (I think we'll need an ATTR_2 interface in the end here, Andreas?) Please apply as an interim fix to the original problem and to the accidental new problems its caused, and I'll push through a new patch in the new year. cheers. -- Nathan --=-dpJpTHodwH2NZsc/s/EW Content-Disposition: attachment; filename=fix-exports-screwup Content-Type: text/x-patch; name=fix-exports-screwup; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: attr/VERSION =================================================================== --- attr.orig/VERSION 2006-12-19 09:44:46.333133250 +1100 +++ attr/VERSION 2006-12-19 09:45:05.570335500 +1100 @@ -3,5 +3,5 @@ # PKG_MAJOR=2 PKG_MINOR=4 -PKG_REVISION=35 +PKG_REVISION=36 PKG_BUILD=0 Index: attr/debian/changelog =================================================================== --- attr.orig/debian/changelog 2006-12-19 09:44:46.417138500 +1100 +++ attr/debian/changelog 2006-12-19 11:25:44.527746750 +1100 @@ -1,3 +1,11 @@ +attr (2.4.36-1) unstable; urgency=high + + * New upstream release + * Reinstate xattr syscall entry points (closes: #403585) + * Fix ARM EABI issue differently, thanks to Lennert Buytenhek. + + -- Nathan Scott Tue, 19 Dec 2006 09:46:05 +1100 + attr (2.4.35-1) unstable; urgency=low * New upstream release Index: attr/doc/CHANGES =================================================================== --- attr.orig/doc/CHANGES 2006-12-19 09:44:46.353134500 +1100 +++ attr/doc/CHANGES 2006-12-19 11:17:54.050343750 +1100 @@ -1,3 +1,9 @@ +attr-2.4.36 (19 December 2006) + - Reinstate xattr syscall entry points (these symbols are + explicitly exported from the library - d'oh!). + - Fix the original ARM EABI issue a different way, thanks + to Lennert Buytenhek. + attr-2.4.35 (8 December 2006) - Remove system call stubs from libattr, we always defer to the libc interfaces in this day and age. Removes a SIGILL Index: attr/libattr/Makefile =================================================================== --- attr.orig/libattr/Makefile 2006-12-19 09:44:59.025926500 +1100 +++ attr/libattr/Makefile 2006-12-19 09:50:08.757283500 +1100 @@ -15,6 +15,12 @@ LT_AGE = 1 CFILES = libattr.c attr_copy_fd.c attr_copy_file.c attr_copy_check.c HFILES = libattr.h +ifeq ($(PKG_PLATFORM),linux) +CFILES += syscalls.c +else +LSRCFILES = syscalls.c +endif + LCFLAGS = -include libattr.h default: $(LTLIBRARY) Index: attr/libattr/syscalls.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ attr/libattr/syscalls.c 2006-12-19 11:17:22.532374000 +1100 @@ -0,0 +1,263 @@ +/* + * Copyright (c) 2001-2002 Silicon Graphics, Inc. + * All Rights Reserved. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it would be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/* + * The use of the syscall() function is an additional level of + * indirection. This avoids the dependency on kernel sources. + */ + +#include +#include + +#if defined (__i386__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_setxattr 226 +# define __NR_lsetxattr 227 +# define __NR_fsetxattr 228 +# define __NR_getxattr 229 +# define __NR_lgetxattr 230 +# define __NR_fgetxattr 231 +# define __NR_listxattr 232 +# define __NR_llistxattr 233 +# define __NR_flistxattr 234 +# define __NR_removexattr 235 +# define __NR_lremovexattr 236 +# define __NR_fremovexattr 237 +#elif defined (__sparc__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_setxattr 169 +# define __NR_lsetxattr 170 +# define __NR_fsetxattr 171 +# define __NR_getxattr 172 +# define __NR_lgetxattr 173 +# define __NR_fgetxattr 177 +# define __NR_listxattr 178 +# define __NR_llistxattr 179 +# define __NR_flistxattr 180 +# define __NR_removexattr 181 +# define __NR_lremovexattr 182 +# define __NR_fremovexattr 186 +#elif defined (__ia64__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_setxattr 1217 +# define __NR_lsetxattr 1218 +# define __NR_fsetxattr 1219 +# define __NR_getxattr 1220 +# define __NR_lgetxattr 1221 +# define __NR_fgetxattr 1222 +# define __NR_listxattr 1223 +# define __NR_llistxattr 1224 +# define __NR_flistxattr 1225 +# define __NR_removexattr 1226 +# define __NR_lremovexattr 1227 +# define __NR_fremovexattr 1228 +#elif defined (__powerpc__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_setxattr 209 +# define __NR_lsetxattr 210 +# define __NR_fsetxattr 211 +# define __NR_getxattr 212 +# define __NR_lgetxattr 213 +# define __NR_fgetxattr 214 +# define __NR_listxattr 215 +# define __NR_llistxattr 216 +# define __NR_flistxattr 217 +# define __NR_removexattr 218 +# define __NR_lremovexattr 219 +# define __NR_fremovexattr 220 +#elif defined (__x86_64__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_setxattr 188 +# define __NR_lsetxattr 189 +# define __NR_fsetxattr 190 +# define __NR_getxattr 191 +# define __NR_lgetxattr 192 +# define __NR_fgetxattr 193 +# define __NR_listxattr 194 +# define __NR_llistxattr 195 +# define __NR_flistxattr 196 +# define __NR_removexattr 197 +# define __NR_lremovexattr 198 +# define __NR_fremovexattr 199 +#elif defined (__s390__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_setxattr 224 +# define __NR_lsetxattr 225 +# define __NR_fsetxattr 226 +# define __NR_getxattr 227 +# define __NR_lgetxattr 228 +# define __NR_fgetxattr 229 +# define __NR_listxattr 230 +# define __NR_llistxattr 231 +# define __NR_flistxattr 232 +# define __NR_removexattr 233 +# define __NR_lremovexattr 234 +# define __NR_fremovexattr 235 +#elif defined (__arm__) +# define HAVE_XATTR_SYSCALLS 1 +# if defined(__ARM_EABI__) || defined(__thumb__) +# define __NR_SYSCALL_BASE 0 +# else +# define __NR_SYSCALL_BASE 0x900000 +# endif +# define __NR_setxattr (__NR_SYSCALL_BASE+226) +# define __NR_lsetxattr (__NR_SYSCALL_BASE+227) +# define __NR_fsetxattr (__NR_SYSCALL_BASE+228) +# define __NR_getxattr (__NR_SYSCALL_BASE+229) +# define __NR_lgetxattr (__NR_SYSCALL_BASE+230) +# define __NR_fgetxattr (__NR_SYSCALL_BASE+231) +# define __NR_listxattr (__NR_SYSCALL_BASE+232) +# define __NR_llistxattr (__NR_SYSCALL_BASE+233) +# define __NR_flistxattr (__NR_SYSCALL_BASE+234) +# define __NR_removexattr (__NR_SYSCALL_BASE+235) +# define __NR_lremovexattr (__NR_SYSCALL_BASE+236) +# define __NR_fremovexattr (__NR_SYSCALL_BASE+237) +#elif defined (__mips64__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_Linux 5000 +# define __NR_setxattr (__NR_Linux + 217) +# define __NR_lsetxattr (__NR_Linux + 218) +# define __NR_fsetxattr (__NR_Linux + 219) +# define __NR_getxattr (__NR_Linux + 220) +# define __NR_lgetxattr (__NR_Linux + 221) +# define __NR_fgetxattr (__NR_Linux + 222) +# define __NR_listxattr (__NR_Linux + 223) +# define __NR_llistxattr (__NR_Linux + 224) +# define __NR_flistxattr (__NR_Linux + 225) +# define __NR_removexattr (__NR_Linux + 226) +# define __NR_lremovexattr (__NR_Linux + 227) +# define __NR_fremovexattr (__NR_Linux + 228) +#elif defined (__mips__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_Linux 4000 +# define __NR_setxattr (__NR_Linux + 224) +# define __NR_lsetxattr (__NR_Linux + 225) +# define __NR_fsetxattr (__NR_Linux + 226) +# define __NR_getxattr (__NR_Linux + 227) +# define __NR_lgetxattr (__NR_Linux + 228) +# define __NR_fgetxattr (__NR_Linux + 229) +# define __NR_listxattr (__NR_Linux + 230) +# define __NR_llistxattr (__NR_Linux + 231) +# define __NR_flistxattr (__NR_Linux + 232) +# define __NR_removexattr (__NR_Linux + 233) +# define __NR_lremovexattr (__NR_Linux + 234) +# define __NR_fremovexattr (__NR_Linux + 235) +#elif defined (__alpha__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_setxattr 382 +# define __NR_lsetxattr 383 +# define __NR_fsetxattr 384 +# define __NR_getxattr 385 +# define __NR_lgetxattr 386 +# define __NR_fgetxattr 387 +# define __NR_listxattr 388 +# define __NR_llistxattr 389 +# define __NR_flistxattr 390 +# define __NR_removexattr 391 +# define __NR_lremovexattr 392 +# define __NR_fremovexattr 393 +#elif defined (__mc68000__) +# define HAVE_XATTR_SYSCALLS 1 +# define __NR_setxattr 223 +# define __NR_lsetxattr 224 +# define __NR_fsetxattr 225 +# define __NR_getxattr 226 +# define __NR_lgetxattr 227 +# define __NR_fgetxattr 228 +# define __NR_listxattr 229 +# define __NR_llistxattr 230 +# define __NR_flistxattr 231 +# define __NR_removexattr 232 +# define __NR_lremovexattr 233 +# define __NR_fremovexattr 234 +#else +# warning "Extended attribute syscalls undefined for this architecture" +# define HAVE_XATTR_SYSCALLS 0 +#endif + +#if HAVE_XATTR_SYSCALLS +# define SYSCALL(args...) syscall(args) +#else +# define SYSCALL(args...) ( errno = ENOSYS, -1 ) +#endif + +int setxattr (const char *path, const char *name, + void *value, size_t size, int flags) +{ + return SYSCALL(__NR_setxattr, path, name, value, size, flags); +} + +int lsetxattr (const char *path, const char *name, + void *value, size_t size, int flags) +{ + return SYSCALL(__NR_lsetxattr, path, name, value, size, flags); +} + +int fsetxattr (int filedes, const char *name, + void *value, size_t size, int flags) +{ + return SYSCALL(__NR_fsetxattr, filedes, name, value, size, flags); +} + +ssize_t getxattr (const char *path, const char *name, + void *value, size_t size) +{ + return SYSCALL(__NR_getxattr, path, name, value, size); +} + +ssize_t lgetxattr (const char *path, const char *name, + void *value, size_t size) +{ + return SYSCALL(__NR_lgetxattr, path, name, value, size); +} + +ssize_t fgetxattr (int filedes, const char *name, + void *value, size_t size) +{ + return SYSCALL(__NR_fgetxattr, filedes, name, value, size); +} + +ssize_t listxattr (const char *path, char *list, size_t size) +{ + return SYSCALL(__NR_listxattr, path, list, size); +} + +ssize_t llistxattr (const char *path, char *list, size_t size) +{ + return SYSCALL(__NR_llistxattr, path, list, size); +} + +ssize_t flistxattr (int filedes, char *list, size_t size) +{ + return SYSCALL(__NR_flistxattr, filedes, list, size); +} + +int removexattr (const char *path, const char *name) +{ + return SYSCALL(__NR_removexattr, path, name); +} + +int lremovexattr (const char *path, const char *name) +{ + return SYSCALL(__NR_lremovexattr, path, name); +} + +int fremovexattr (int filedes, const char *name) +{ + return SYSCALL(__NR_fremovexattr, filedes, name); +} --=-dpJpTHodwH2NZsc/s/EW-- From owner-xfs@oss.sgi.com Mon Dec 18 18:53:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 18:53:40 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBJ2rXqw028437 for ; Mon, 18 Dec 2006 18:53:35 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA28887; Tue, 19 Dec 2006 13:52:34 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBJ2qW7Y66564738; Tue, 19 Dec 2006 13:52:32 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBJ2qTAT66673664; Tue, 19 Dec 2006 13:52:29 +1100 (AEDT) Date: Tue, 19 Dec 2006 13:52:29 +1100 From: David Chinner To: Haar =?iso-8859-1?Q?J=E1nos?= Cc: David Chinner , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: xfslogd-spinlock bug? Message-ID: <20061219025229.GT33919298@melbourne.sgi.com> References: <003701c71d78$33ed28d0$0400a8c0@dcccs> <00ab01c71e53$942af2f0$0400a8c0@dcccs> <000d01c72127$3d7509b0$0400a8c0@dcccs> <20061217224457.GN33919298@melbourne.sgi.com> <026501c72237$0464f7a0$0400a8c0@dcccs> <20061218062444.GH44411608@melbourne.sgi.com> <027b01c7227d$0e26d1f0$0400a8c0@dcccs> <20061218223637.GP44411608@melbourne.sgi.com> <001a01c722fd$df5ca710$0400a8c0@dcccs> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <001a01c722fd$df5ca710$0400a8c0@dcccs> User-Agent: Mutt/1.4.2.1i X-archive-position: 10039 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2911 Lines: 94 On Tue, Dec 19, 2006 at 12:39:46AM +0100, Haar János wrote: > From: "David Chinner" > > On Mon, Dec 18, 2006 at 09:17:50AM +0100, Haar János wrote: > > > From: "David Chinner" > > > > Ok, I've never heard of a problem like this before and you are doing > > > > something that very few ppl are doing (i.e. XFS on NBD). I'd start > > > > Hence I'd start by suspecting a bug in the NBD driver. > > > > > > Ok, if you have right, this also can be in context with the following > issue: > > > > > > http://download.netcenter.hu/bughunt/20061217/messages.txt (10KB) > > > > Which appears to be a crash in wake_up_process() when doing memory > > reclaim (waking the xfsbufd). > > Sorry, can you translate it to "poor mans language"? :-) > This is a different bug? Don't know - it's a different crash, but once again one that I've never heard of occurring before. > > Ok, I've found this pattern: > > > > #define POISON_FREE 0x6b > > > > Can you confirm that you are running with CONFIG_DEBUG_SLAB=y? > > Yes, i build with this option enabled. > Is this wrong? No, but it does slow your machine down. > > If so, we have a use after free occurring here and it would also > > explain why no-one has reported it before. > > > > FWIW, can you turn on CONFIG_XFS_DEBUG=y and see if that triggers > > a different bug check prior to the above dump? > > [root@X64 linux-2.6.19]# make bzImage > scripts/kconfig/conf -s arch/x86_64/Kconfig > .config:7:warning: trying to assign nonexistent symbol XFS_DEBUG > > I have missed something? No - I forgot that config option doesn't exist in mainline XFS - it's only in the dev tree. FWIW, I've run XFSQA twice now on a scsi disk with slab debuggin turned on and I haven't seen this problem. I'm not sure how to track down the source of the problem without a test case, but as a quick test, can you try the following patch? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.6/xfs_buf.c | 4 ++++ 1 file changed, 4 insertions(+) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_buf.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_buf.c 2006-12-19 12:22:54.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_buf.c 2006-12-19 13:48:36.937118569 +1100 @@ -942,11 +942,14 @@ xfs_buf_unlock( /* * Pinning Buffer Storage in Memory * Ensure that no attempt to force a buffer to disk will succeed. + * Hold the buffer so we don't attempt to free it while it + * is pinned. */ void xfs_buf_pin( xfs_buf_t *bp) { + xfs_buf_hold(bp); atomic_inc(&bp->b_pin_count); XB_TRACE(bp, "pin", (long)bp->b_pin_count.counter); } @@ -958,6 +961,7 @@ xfs_buf_unpin( if (atomic_dec_and_test(&bp->b_pin_count)) wake_up_all(&bp->b_waiters); XB_TRACE(bp, "unpin", (long)bp->b_pin_count.counter); + xfs_buf_rele(bp); } int From owner-xfs@oss.sgi.com Mon Dec 18 20:48:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 20:48:12 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBJ4m4qw014371 for ; Mon, 18 Dec 2006 20:48:06 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA02016; Tue, 19 Dec 2006 15:47:06 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBJ4l37Y65964544; Tue, 19 Dec 2006 15:47:04 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBJ4l0Do66716463; Tue, 19 Dec 2006 15:47:00 +1100 (AEDT) Date: Tue, 19 Dec 2006 15:47:00 +1100 From: David Chinner To: David Chinner Cc: Haar =?iso-8859-1?Q?J=E1nos?= , linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: xfslogd-spinlock bug? Message-ID: <20061219044700.GW33919298@melbourne.sgi.com> References: <00ab01c71e53$942af2f0$0400a8c0@dcccs> <000d01c72127$3d7509b0$0400a8c0@dcccs> <20061217224457.GN33919298@melbourne.sgi.com> <026501c72237$0464f7a0$0400a8c0@dcccs> <20061218062444.GH44411608@melbourne.sgi.com> <027b01c7227d$0e26d1f0$0400a8c0@dcccs> <20061218223637.GP44411608@melbourne.sgi.com> <001a01c722fd$df5ca710$0400a8c0@dcccs> <20061219025229.GT33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20061219025229.GT33919298@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 10040 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2520 Lines: 63 On Tue, Dec 19, 2006 at 01:52:29PM +1100, David Chinner wrote: > On Tue, Dec 19, 2006 at 12:39:46AM +0100, Haar János wrote: > > From: "David Chinner" > > > #define POISON_FREE 0x6b > > > > > > Can you confirm that you are running with CONFIG_DEBUG_SLAB=y? > > > > Yes, i build with this option enabled. ...... > FWIW, I've run XFSQA twice now on a scsi disk with slab debuggin turned > on and I haven't seen this problem. I'm not sure how to track down > the source of the problem without a test case, but as a quick test, can > you try the following patch? Third try an I got a crash on a poisoned object: [1]kdb> md8c40 e00000300d7d5100 0xe00000300d7d5100 000000005a2cf071 0000000000000000 q.,Z............ 0xe00000300d7d5110 000000005a2cf071 6b6b6b6b6b6b6b6b q.,Z....kkkkkkkk 0xe00000300d7d5120 e0000039eb7b6320 6b6b6b6b6b6b6b6b c{.9...kkkkkkkk 0xe00000300d7d5130 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk 0xe00000300d7d5140 6b6b6b6f6b6b6b6b 6b6b6b6b6b6b6b6b kkkkokkkkkkkkkkk 0xe00000300d7d5150 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk 0xe00000300d7d5160 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk 0xe00000300d7d5170 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk 0xe00000300d7d5180 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk 0xe00000300d7d5190 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk 0xe00000300d7d51a0 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk 0xe00000300d7d51b0 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk 0xe00000300d7d51c0 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk 0xe00000300d7d51d0 6b6b6b6b6b6b6b6b a56b6b6b6b6b6b6b kkkkkkkkkkkkkkk. 0xe00000300d7d51e0 000000005a2cf071 a000000100468c30 q.,Z....0.F..... [1]kdb> mds 0xe00000300d7d51e0 0xe00000300d7d51e0 5a2cf071 q.,Z.... 0xe00000300d7d51e8 a000000100468c30 xfs_inode_item_destroy+0x30 So the use-after-free here is on an inode item. You're tripping over a buffer item. Unfortunately, it is not the same problem - the problem I've just hit is to do with a QA test that does a forced shutdown on an active filesystem, and: [1]kdb> xmount 0xe00000304393e238 ..... flags 0x440010 The filesystem was being shutdown so xfs_inode_item_destroy() just frees the inode log item without removing it from the AIL. I'll fix that, and see if i have any luck.... So I'd still try that patch i sent in the previous email... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Mon Dec 18 21:31:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 21:31:18 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBJ5VAqw020375 for ; Mon, 18 Dec 2006 21:31:13 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA03147; Tue, 19 Dec 2006 16:30:14 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBJ5UD7Y66623746; Tue, 19 Dec 2006 16:30:14 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBJ5UC7p66596445; Tue, 19 Dec 2006 16:30:12 +1100 (AEDT) Date: Tue, 19 Dec 2006 16:30:12 +1100 From: David Chinner To: xfs-dev@sgi.com Cc: xfs@oss.sgi.com Subject: Review: Fix use after free on forced shutdown Message-ID: <20061219053012.GY33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 10041 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1635 Lines: 54 As found earlier today trying to reproduce a different use after free, a machine with CONFIG_SLAB_DEBUG will panic on a forced shutdown if the inode has an assocaited item in the AIL. Trivial fix is to remove the item from the AIL before freeing it. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_inode.c | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/xfs_inode.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_inode.c 2006-12-12 15:40:58.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_inode.c 2006-12-19 15:44:09.675298719 +1100 @@ -2704,10 +2704,24 @@ xfs_idestroy( ktrace_free(ip->i_dir_trace); #endif if (ip->i_itemp) { - /* XXXdpd should be able to assert this but shutdown - * is leaving the AIL behind. */ - ASSERT(((ip->i_itemp->ili_item.li_flags & XFS_LI_IN_AIL) == 0) || - XFS_FORCED_SHUTDOWN(ip->i_mount)); + /* + * Only if we are shutting down the fs will we see an + * inode still in the AIL. If it is there, we should remove + * it to prevent a use-after-free from occurring. + */ + xfs_mount_t *mp = ip->i_mount; + xfs_log_item_t *lip = &ip->i_itemp->ili_item; + int s; + + ASSERT(((lip->li_flags & XFS_LI_IN_AIL) == 0) || + XFS_FORCED_SHUTDOWN(ip->i_mount)); + if (lip->li_flags & XFS_LI_IN_AIL) { + AIL_LOCK(mp, s); + if (lip->li_flags & XFS_LI_IN_AIL) + xfs_trans_delete_ail(mp, lip, s); + else + AIL_UNLOCK(mp, s); + } xfs_inode_item_destroy(ip); } kmem_zone_free(xfs_inode_zone, ip); From owner-xfs@oss.sgi.com Mon Dec 18 22:08:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 22:08:14 -0800 (PST) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBJ687qw024660 for ; Mon, 18 Dec 2006 22:08:08 -0800 Received: from localhost ([192.168.0.78]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id kBJ674gg007904; Tue, 19 Dec 2006 09:07:05 +0300 (MSK) To: David Chinner Cc: Dmitriy Monakhov , linux-kernel@vger.kernel.org, devel@openvz.org, Andrew Morton , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect direct io error handling References: <87d56he3tn.fsf@sw.ru> <20061218221515.GN44411608@melbourne.sgi.com> From: Dmitriy Monakhov Date: Tue, 19 Dec 2006 09:07:12 +0300 In-Reply-To: <20061218221515.GN44411608@melbourne.sgi.com> (David Chinner's message of "Tue, 19 Dec 2006 09:15:15 +1100") Message-ID: <87psagto4v.fsf@sw.ru> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 10042 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dmonakhov@sw.ru Precedence: bulk X-list: xfs Content-Length: 3912 Lines: 98 David Chinner writes: > On Mon, Dec 18, 2006 at 04:22:44PM +0300, Dmitriy Monakhov wrote: >> diff --git a/mm/filemap.c b/mm/filemap.c >> index 8332c77..7c571dd 100644 >> --- a/mm/filemap.c >> +++ b/mm/filemap.c >> @@ -2044,8 +2044,9 @@ generic_file_direct_write(struct kiocb * >> /* >> * Sync the fs metadata but not the minor inode changes and >> * of course not the data as we did direct DMA for the IO. >> - * i_mutex is held, which protects generic_osync_inode() from >> - * livelocking. AIO O_DIRECT ops attempt to sync metadata here. >> + * i_mutex may not being held (XFS does this), if so some specific locking >> + * ordering must protect generic_osync_inode() from livelocking. >> + * AIO O_DIRECT ops attempt to sync metadata here. >> */ >> if ((written >= 0 || written == -EIOCBQUEUED) && >> ((file->f_flags & O_SYNC) || IS_SYNC(inode))) { >> @@ -2279,6 +2280,17 @@ __generic_file_aio_write_nolock(struct k >> >> written = generic_file_direct_write(iocb, iov, &nr_segs, pos, >> ppos, count, ocount); >> + /* >> + * If host is not S_ISBLK generic_file_direct_write() may >> + * have instantiated a few blocks outside i_size files >> + * Trim these off again. >> + */ >> + if (unlikely(written < 0) && !S_ISBLK(inode->i_mode)) { >> + loff_t isize = i_size_read(inode); >> + if (pos + count > isize) >> + vmtruncate(inode, isize); >> + } >> + >> if (written < 0 || written == count) >> goto out; > > You comment in the first hunk that i_mutex may not be held here, > but there's no comment in __generic_file_aio_write_nolock() that the > i_mutex must be held for !S_ISBLK devices. Any one may call directly call generic_file_direct_write() with i_mutex not held. > >> @@ -2341,6 +2353,13 @@ ssize_t generic_file_aio_write_nolock(st >> ssize_t ret; >> >> BUG_ON(iocb->ki_pos != pos); >> + /* >> + * generic_file_buffered_write() may be called inside >> + * __generic_file_aio_write_nolock() even in case of >> + * O_DIRECT for non S_ISBLK files. So i_mutex must be held. >> + */ >> + if (!S_ISBLK(inode->i_mode)) >> + BUG_ON(!mutex_is_locked(&inode->i_mutex)); >> >> ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, >> &iocb->ki_pos); > > I note that you comment here in generic_file_aio_write_nolock(), > but it's not immediately obvious that this is refering to the > vmtruncate() call in __generic_file_aio_write_nolock(). This is not about vmtruncate(). __generic_file_aio_write_nolock() may call generic_file_buffered_write() even in case of O_DIRECT for !S_ISBLK, and generic_file_buffered_write() has documented locking rules (i_mutex held). IMHO it is important to explicitly document this . And after we realize that i_mutex always held, vmtruncate() may be safely called. > > IOWs, wouldn't it be better to put this comment and check in > __generic_file_aio_write_nolock() directly above the vmtruncate() > call that cares about this? > >> @@ -2383,8 +2402,8 @@ ssize_t generic_file_aio_write(struct ki >> EXPORT_SYMBOL(generic_file_aio_write); >> >> /* >> - * Called under i_mutex for writes to S_ISREG files. Returns -EIO if something >> - * went wrong during pagecache shootdown. >> + * May be called without i_mutex for writes to S_ISREG files. XFS does this. >> + * Returns -EIO if something went wrong during pagecache shootdown. >> */ > > Not sure you need to say "XFS does this" - other filesystems may do this > in the future..... Yes, but where are multiple comments about "reiserfs does this" in fs/buffer.c > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ From owner-xfs@oss.sgi.com Mon Dec 18 22:32:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 22:32:23 -0800 (PST) Received: from relay.sw.ru (mailhub.sw.ru [195.214.233.200]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBJ6WGqw028254 for ; Mon, 18 Dec 2006 22:32:18 -0800 Received: from localhost ([192.168.0.78]) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id kBJ6V5o2007447; Tue, 19 Dec 2006 09:31:06 +0300 (MSK) To: "Chen, Kenneth W" Cc: "'Dmitriy Monakhov'" , , , "Andrew Morton" , Subject: Re: [PATCH] incorrect direct io error handling References: <000101c722de$9fdca4b0$e834030a@amr.corp.intel.com> From: Dmitriy Monakhov Date: Tue, 19 Dec 2006 09:31:15 +0300 In-Reply-To: <000101c722de$9fdca4b0$e834030a@amr.corp.intel.com> (Kenneth W. Chen's message of "Mon, 18 Dec 2006 11:56:36 -0800") Message-ID: <87lkl4tn0s.fsf@sw.ru> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-archive-position: 10043 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dmonakhov@sw.ru Precedence: bulk X-list: xfs Content-Length: 1794 Lines: 34 "Chen, Kenneth W" writes: > Dmitriy Monakhov wrote on Monday, December 18, 2006 5:23 AM >> This patch is result of discussion started week ago here: >> http://lkml.org/lkml/2006/12/11/66 >> changes from original patch: >> - Update wrong comments about i_mutex locking. >> - Add BUG_ON(!mutex_is_locked(..)) for non blkdev. >> - vmtruncate call only for non blockdev >> LOG: >> If generic_file_direct_write() has fail (ENOSPC condition) inside >> __generic_file_aio_write_nolock() it may have instantiated >> a few blocks outside i_size. And fsck will complain about wrong i_size >> (ext2, ext3 and reiserfs interpret i_size and biggest block difference as error), >> after fsck will fix error i_size will be increased to the biggest block, >> but this blocks contain gurbage from previous write attempt, this is not >> information leak, but its silence file data corruption. This issue affect >> fs regardless the values of blocksize or pagesize. >> We need truncate any block beyond i_size after write have failed , do in simular >> generic_file_buffered_write() error path. If host is !S_ISBLK i_mutex always >> held inside generic_file_aio_write_nolock() and we may safely call vmtruncate(). >> Some fs (XFS at least) may directly call generic_file_direct_write()with >> i_mutex not held. There is no general scenario in this case. This fs have to >> handle generic_file_direct_write() error by its own specific way (place). > > > I'm puzzled that if ext2 is able to instantiate some blocks, then why does it > return no space error? Where is the error coming from? generic_file_aio_write_nolock() ->generic_file_direct_write() ->generic_file_direct_IO() ->ext2_direct_IO(WRITE,...) ->blockdev_direct_IO( ....,ext2_get_block,...) From owner-xfs@oss.sgi.com Mon Dec 18 23:39:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 18 Dec 2006 23:39:19 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBJ7dCqw005720 for ; Mon, 18 Dec 2006 23:39:13 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GwZYK-0003SO-FY for linux-xfs@oss.sgi.com; Tue, 19 Dec 2006 08:38:20 +0100 Received: from finn.gmane.org ([80.91.229.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Dec 2006 08:38:20 +0100 Received: from mszpak by finn.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 19 Dec 2006 08:38:20 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: =?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?= Subject: Re: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed Date: Tue, 19 Dec 2006 08:38:59 +0100 Message-ID: References: <200612180118.MAA21311@larry.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: finn.gmane.org User-Agent: Thunderbird 1.5.0.8 (X11/20061107) In-Reply-To: X-archive-position: 10044 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mszpak@wp.pl Precedence: bulk X-list: xfs Content-Length: 2740 Lines: 63 Marcin Zaj±czkowski wrote: > Barry Naujok wrote: >>> Subject: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed > (...) >>> Recently I've got rescue CD with xfs_progs in version 2.8.11 and >>> tried to repair it. xfs_repair gave me about 150 files with names >>> like inode numbers in /lost+found and 1500 "normal" named files in >>> its subdirectory. >>> I've tried to use "xfs_ncheck -i inode /dev/hdX" to got names >>> corresponding with specified inode(s), but program had been runing >>> several minutes, xfs_db had eaten all available memory (768MB) and >>> was killed by system (whole system hung too). The second time I >>> killed it (kill -15) when it ate whole available memory. >>> My file system has about 6GB and is filled with 95%. >> >> This is the second report of a smallish filesystem using all of the >> system's memory (the other being xfs_repair). Hopefully when I diagnose >> the problem with the previous report, I can fix the same issue with >> xfs_db and your filesystem. >> >> If it at all possible, can you xfs_copy the offending filesystem to a >> file and compress it and make it available to me to find/fix the >> problem. > > Hmm, it won't be so easy. Compressed dump of a fielsystem before repair > (I had to use dd, because xfsdump refused to cooperate) has 2,5GB. > Damaged files were (probably) only in one directory /usr/bin. Maybe I > could reduce size of the image excluding few other directories (in > xfsdump)? > Do you think that error would still occur? What do you think about that? Btw, is it possible to mount XFS filesystem from the file created by xfs_copy? If not, is it possible to restore file system "backuped" to file (by xfs_copy)? I read in the manual that the first parameter xfs_copy has to be device (not file). xfs_restore will work with that "dump"? >>> Am I doing something wrong with xfs_db? >>> Is there any easier way to restore my files? >> >> Your files have been restored as much as possible. You'll have to work >> out what is in lost+found and move them back to their appropriate >> locations. > > With files with "normal" names there is no problem. There are all from > one directory (/usr/bin), but I'm unable (without xfs_ncheck) to map > files with inode-like names with their normal names (150+ files). I > tried with xfs_db and the way described in your FAQ, but I had some > problems too. Currently I have to use LiveCD (/usr/bin is a quite important directory ;) ). Do you suggest to try to repair it manually (copy files with names, try to boot and try to use RPM to repair broken packages (restore missing files) or there could be an easiest way (at the xfs layer to match numbers with proper names)? Regards Marcin From owner-xfs@oss.sgi.com Tue Dec 19 02:35:50 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 19 Dec 2006 02:35:55 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBJAZmqw006074 for ; Tue, 19 Dec 2006 02:35:50 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1GwbqM-00063d-Sq; Tue, 19 Dec 2006 10:05:06 +0000 Date: Tue, 19 Dec 2006 10:05:06 +0000 From: Christoph Hellwig To: Nathan Scott Cc: bnaujok@sgi.com, xfs@oss.sgi.com, agruen@suse.de Subject: Re: [PATCH] rethink removal of xattr syscall stubs (for now) Message-ID: <20061219100506.GA22779@infradead.org> References: <1166490658.5572.89.camel@edge> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1166490658.5572.89.camel@edge> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10046 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 879 Lines: 20 On Tue, Dec 19, 2006 at 12:10:58PM +1100, Nathan Scott wrote: > Hi, > > It turns out (*cough*) that we use an export file with libattr, > that I completely forgot about, which specifies the *xattr calls > as part of the ATTR_1 interface. This patch reverts the syscall > stub removal patch from before, includes Lennerts patch to fix > the original problem ARM EABI, and I'll go think some more about > how to properly fix this (I think we'll need an ATTR_2 interface > in the end here, Andreas?) > > Please apply as an interim fix to the original problem and to > the accidental new problems its caused, and I'll push through a > new patch in the new year. There is a way to re-export symbols you imported from another library with symbol versioning. That how for example libpthread works on recent Solaris versions. I'll find out how exactly that should be implemented. From owner-xfs@oss.sgi.com Tue Dec 19 08:54:02 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 19 Dec 2006 08:54:08 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBJGs0qw027217 for ; Tue, 19 Dec 2006 08:54:01 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBJGr7Vd017310; Tue, 19 Dec 2006 11:53:07 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBJGr6TO020831; Tue, 19 Dec 2006 11:53:06 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBJGr2Jf022904; Tue, 19 Dec 2006 11:53:04 -0500 Message-ID: <458818ED.1040208@sandeen.net> Date: Tue, 19 Dec 2006 10:53:01 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: xfs@oss.sgi.com CC: Christoph Hellwig Subject: Re: [PATCH] use vfs-defined file attribute flags References: <45819221.70502@sandeen.net> <20061214181500.GA13856@infradead.org> <45819630.3070701@sandeen.net> In-Reply-To: <45819630.3070701@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10049 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 2609 Lines: 92 Eric Sandeen wrote: > Christoph Hellwig wrote: > >> Just kill the defines completly and use the FS_ flags Ugh maybe I should test build when I change stuff eh. This one builds, even :) Signed-off-by: Eric Sandeen Index: linux-2.6.19/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6.19.orig/fs/xfs/linux-2.6/xfs_ioctl.c +++ linux-2.6.19/fs/xfs/linux-2.6/xfs_ioctl.c @@ -1095,11 +1095,6 @@ xfs_ioc_fsgeometry( /* * Linux extended inode flags interface. */ -#define LINUX_XFLAG_SYNC 0x00000008 /* Synchronous updates */ -#define LINUX_XFLAG_IMMUTABLE 0x00000010 /* Immutable file */ -#define LINUX_XFLAG_APPEND 0x00000020 /* writes to file may only append */ -#define LINUX_XFLAG_NODUMP 0x00000040 /* do not dump file */ -#define LINUX_XFLAG_NOATIME 0x00000080 /* do not update atime */ STATIC unsigned int xfs_merge_ioc_xflags( @@ -1108,23 +1103,23 @@ xfs_merge_ioc_xflags( { unsigned int xflags = start; - if (flags & LINUX_XFLAG_IMMUTABLE) + if (flags & FS_IMMUTABLE_FL) xflags |= XFS_XFLAG_IMMUTABLE; else xflags &= ~XFS_XFLAG_IMMUTABLE; - if (flags & LINUX_XFLAG_APPEND) + if (flags & FS_APPEND_FL) xflags |= XFS_XFLAG_APPEND; else xflags &= ~XFS_XFLAG_APPEND; - if (flags & LINUX_XFLAG_SYNC) + if (flags & FS_SYNC_FL) xflags |= XFS_XFLAG_SYNC; else xflags &= ~XFS_XFLAG_SYNC; - if (flags & LINUX_XFLAG_NOATIME) + if (flags & FS_NOATIME_FL) xflags |= XFS_XFLAG_NOATIME; else xflags &= ~XFS_XFLAG_NOATIME; - if (flags & LINUX_XFLAG_NODUMP) + if (flags & FS_NODUMP_FL) xflags |= XFS_XFLAG_NODUMP; else xflags &= ~XFS_XFLAG_NODUMP; @@ -1139,15 +1134,15 @@ xfs_di2lxflags( unsigned int flags = 0; if (di_flags & XFS_DIFLAG_IMMUTABLE) - flags |= LINUX_XFLAG_IMMUTABLE; + flags |= FS_IMMUTABLE_FL; if (di_flags & XFS_DIFLAG_APPEND) - flags |= LINUX_XFLAG_APPEND; + flags |= FS_APPEND_FL; if (di_flags & XFS_DIFLAG_SYNC) - flags |= LINUX_XFLAG_SYNC; + flags |= FS_SYNC_FL; if (di_flags & XFS_DIFLAG_NOATIME) - flags |= LINUX_XFLAG_NOATIME; + flags |= FS_NOATIME_FL; if (di_flags & XFS_DIFLAG_NODUMP) - flags |= LINUX_XFLAG_NODUMP; + flags |= FS_NODUMP_FL; return flags; } @@ -1247,9 +1242,9 @@ xfs_ioc_xattr( break; } - if (flags & ~(LINUX_XFLAG_IMMUTABLE | LINUX_XFLAG_APPEND | \ - LINUX_XFLAG_NOATIME | LINUX_XFLAG_NODUMP | \ - LINUX_XFLAG_SYNC)) { + if (flags & ~(FS_IMMUTABLE_FL | FS_APPEND_FL | \ + FS_NOATIME_FL | FS_NODUMP_FL | \ + FS_SYNC_FL)) { error = -EOPNOTSUPP; break; } From owner-xfs@oss.sgi.com Tue Dec 19 09:17:43 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 19 Dec 2006 09:17:47 -0800 (PST) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBJHHgqw029737 for ; Tue, 19 Dec 2006 09:17:43 -0800 Received: from [134.15.160.25] (vpn-emea-sw-emea-160-25.emea.sgi.com [134.15.160.25]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kBJGtFqW73333078; Tue, 19 Dec 2006 08:55:16 -0800 (PST) Message-ID: <45881E7F.1070604@sgi.com> Date: Tue, 19 Dec 2006 17:16:47 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Steigerwald CC: linux-xfs@oss.sgi.com, xfs-dev@sgi.com Subject: Re: hints on how to help debugging as FAQ entry (Re: invalid directory entry - bad magic number on inode) References: <200612082100.00395.Martin@lichtvoll.de> <200612112111.08209.Martin@lichtvoll.de> <457DFA6A.9050200@sgi.com> <200612121025.42895.Martin@lichtvoll.de> In-Reply-To: <200612121025.42895.Martin@lichtvoll.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10050 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 2829 Lines: 70 Martin Steigerwald wrote: > Am Dienstag 12 Dezember 2006 01:40 schrieb Lachlan McIlroy: > > >>>You are welcome. Without further info reporting it to the bugtracker >>>doesn't make much sense to me. I will keep an eye on it. If it >>>happens again, I will try the hints you gave me. I run xfs_check >>>anyway and thus can easily give it a "-v >xfs_check.txt". I thought I >>>would have to use xfs_db stuff to get further info. >> >>Now that you mention it, printing out the inode in xfs_db might be >>useful. > > > Hello Lachlan, > > well I can do that too... my problem is just: As I use the notebook for > daily work I have to fix it up quickly when problems arise. So usually I > can not afford to report first and await instructions on what to do. I > also currently often have no storage space left to store the complete > partition onto. > > So ideally I have some hints on how to help debugging before an incident > happens. I think this would make a nice FAQ entry, too. > > It could contain: > > 1) xfs_check -v > 2) xfs_check -v -i > 3) xfs_db stuff > 4) probably some hints to determine a useful range for dd / ddrescue from > xfs_check output so that people with either very large partitions or low > storage space can just copy a part of the defect partition for > inspection. Well if thats useful. A complete partition would still be > better cause it is possible to use the XFS tools on it Since the tools wont operate on a fragment of a partition I don't think this would be feasible. It might be possible to debug a single allocation group on it's own but not right now as far as I'm aware. > 5) probably some hints on how to store a partition in a file with > compression... somewhere along the lines of piping dd into bzip2 and > bzip2 into a file. maybe "cat /dev/hda1 | bzip2 >mypartition" Is this so that the problem can be debugged while the filesystem is still in use or is repaired? If the file system can be repaired then the output from repair should be enough to tell us what the problem is (the cause is another matter but we're unlikely to get more information from a dump of the partition). If the partition cannot be repaired then I don't see a point in dumping the partition to a file since the filesystem needs to be fixed before it should be used again. > > What do you think? Sounds good. Our FAQ is lacking in bug triage processes so any hints to gather additional information would be a welcome addition. > > Those hints could help XFS developers to get useful bug reports... > > I am willing to collect the hints and writing a FAQ entry about it that > you can include in your FAQ. > > Well that would probably basically be an extension to: > > " Q: What information should I include when reporting a problem?" > > Regards, From owner-xfs@oss.sgi.com Tue Dec 19 15:31:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 19 Dec 2006 15:31:29 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBJNVKqw007731 for ; Tue, 19 Dec 2006 15:31:23 -0800 Received: from [192.168.5.76] (unknown [124.178.235.100]) by postoffice.aconex.com (Postfix) with ESMTP id 7A7B7AAC206; Wed, 20 Dec 2006 10:23:50 +1100 (EST) Subject: Re: [PATCH] rethink removal of xattr syscall stubs (for now) From: Nathan Scott Reply-To: nscott@aconex.com To: Christoph Hellwig Cc: bnaujok@sgi.com, xfs@oss.sgi.com, agruen@suse.de In-Reply-To: <20061219100506.GA22779@infradead.org> References: <1166490658.5572.89.camel@edge> <20061219100506.GA22779@infradead.org> Content-Type: text/plain Organization: Aconex Date: Wed, 20 Dec 2006 10:31:09 +1100 Message-Id: <1166571069.5572.117.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 10052 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 498 Lines: 15 On Tue, 2006-12-19 at 10:05 +0000, Christoph Hellwig wrote: | > Please apply as an interim fix to the original problem and to | > the accidental new problems its caused, and I'll push through a | > new patch in the new year. | | There is a way to re-export symbols you imported from another | library with symbol versioning. That how for example libpthread | works on recent Solaris versions. I'll find out how exactly that | should be implemented. Ah, that sounds ideal - thanks! -- Nathan From owner-xfs@oss.sgi.com Tue Dec 19 16:49:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 19 Dec 2006 16:49:44 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBK0naqw019738 for ; Tue, 19 Dec 2006 16:49:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04080; Wed, 20 Dec 2006 11:48:41 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBK0mf7Y67449983; Wed, 20 Dec 2006 11:48:41 +1100 (AEDT) Received: (from bnaujok@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBK0mdWR67637476; Wed, 20 Dec 2006 11:48:39 +1100 (AEDT) Date: Wed, 20 Dec 2006 11:48:39 +1100 (AEDT) From: Barry Naujok Message-Id: <200612200048.kBK0mdWR67637476@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 959034 - Fix debian breakage with last attr patch X-archive-position: 10053 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1090 Lines: 25 Fix link breakage in debian with last patch Date: Wed Dec 20 11:48:02 AEDT 2006 Workarea: snort.melbourne.sgi.com:/home/bnaujok/isms/repair Inspected by: nathans@debian.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:27779a attr/VERSION - 1.66 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.66&r2=text&tr2=1.65&f=h attr/doc/CHANGES - 1.78 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.78&r2=text&tr2=1.77&f=h attr/libattr/Makefile - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libattr/Makefile.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h attr/debian/changelog - 1.68 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/changelog.diff?r1=text&tr1=1.68&r2=text&tr2=1.67&f=h attr/libattr/syscalls.c - 1.18 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/libattr/syscalls.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - Fix link breakage in debian with last patch From owner-xfs@oss.sgi.com Tue Dec 19 17:00:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 19 Dec 2006 17:00:48 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBK10fqw021526 for ; Tue, 19 Dec 2006 17:00:43 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04335; Wed, 20 Dec 2006 11:59:49 +1100 Message-Id: <200612200059.LAA04335@larry.melbourne.sgi.com> From: "Barry Naujok" To: "=?iso-8859-2?Q?'Marcin_Zaj=B1czkowski'?=" , Subject: RE: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed Date: Wed, 20 Dec 2006 12:05:47 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccjQM29eKxts5GIQJKy4VFPCAhKvgAkPG5Q Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id kBK10iqw021531 X-archive-position: 10054 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 3934 Lines: 101 > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Marcin Zajaczkowski > Sent: Tuesday, 19 December 2006 6:39 PM > To: linux-xfs@oss.sgi.com > Subject: Re: xfs_ncheck (actually xfs_db) eats a lot of > memory and is killed > > Marcin Zaj±czkowski wrote: > > Barry Naujok wrote: > >>> Subject: xfs_ncheck (actually xfs_db) eats a lot of > memory and is killed > > (...) > >>> Recently I've got rescue CD with xfs_progs in version 2.8.11 and > >>> tried to repair it. xfs_repair gave me about 150 files with names > >>> like inode numbers in /lost+found and 1500 "normal" named > files in > >>> its subdirectory. > >>> I've tried to use "xfs_ncheck -i inode /dev/hdX" to got names > >>> corresponding with specified inode(s), but program had > been runing > >>> several minutes, xfs_db had eaten all available memory > (768MB) and > >>> was killed by system (whole system hung too). The second time I > >>> killed it (kill -15) when it ate whole available memory. > >>> My file system has about 6GB and is filled with 95%. > >> > >> This is the second report of a smallish filesystem using all of the > >> system's memory (the other being xfs_repair). Hopefully > when I diagnose > >> the problem with the previous report, I can fix the same issue with > >> xfs_db and your filesystem. > >> > >> If it at all possible, can you xfs_copy the offending > filesystem to a > >> file and compress it and make it available to me to find/fix the > >> problem. > > > > Hmm, it won't be so easy. Compressed dump of a fielsystem > before repair > > (I had to use dd, because xfsdump refused to cooperate) has 2,5GB. > > Damaged files were (probably) only in one directory > /usr/bin. Maybe I > > could reduce size of the image excluding few other directories (in > > xfsdump)? > > Do you think that error would still occur? > > What do you think about that? xfs_dump won't recreate the filesystem that causes xfs_db to gobble up memory unfortunately, xfs_copy copies the filesystem as it is, block for block. > Btw, is it possible to mount XFS filesystem from the file created by > xfs_copy? > If not, is it possible to restore file system "backuped" to file (by > xfs_copy)? I read in the manual that the first parameter > xfs_copy has to > be device (not file). xfs_restore will work with that "dump"? Yes, you can mount an XFS filesystem file using the "-o loop" mount option and specifying the file for the device. Yes, you can xfs_copy from a file back to a device. From the man page: "The first (source) argument must be the pathname of the device or file containing the XFS filesystem.". xfs_dump/xfs_restore is more like tar copying all metadata, but not disk layout. > >>> Am I doing something wrong with xfs_db? > >>> Is there any easier way to restore my files? > >> > >> Your files have been restored as much as possible. You'll > have to work > >> out what is in lost+found and move them back to their appropriate > >> locations. > > > > With files with "normal" names there is no problem. There > are all from > > one directory (/usr/bin), but I'm unable (without > xfs_ncheck) to map > > files with inode-like names with their normal names (150+ files). I > > tried with xfs_db and the way described in your FAQ, but I had some > > problems too. > > Currently I have to use LiveCD (/usr/bin is a quite important > directory > ;) ). Do you suggest to try to repair it manually (copy files with > names, try to boot and try to use RPM to repair broken packages > (restore missing files) or there could be an easiest way (at the xfs > layer to match numbers with proper names)? If the /usr/bin directory was trashed, I think you can only restore from the original packages, I don't think you'll have much luck doing it manually. (xfs_repair 2.8.10 onwards will restore the same files that the manual approach can retrieve.) From owner-xfs@oss.sgi.com Tue Dec 19 22:29:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 19 Dec 2006 22:29:31 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBK6TJqw022586 for ; Tue, 19 Dec 2006 22:29:23 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA12387; Wed, 20 Dec 2006 17:28:17 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBK6SF7Y67431075; Wed, 20 Dec 2006 17:28:16 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBK6SEe767746097; Wed, 20 Dec 2006 17:28:14 +1100 (AEDT) Date: Wed, 20 Dec 2006 17:28:13 +1100 From: David Chinner To: xfs-dev@sgi.com Cc: xfs@oss.sgi.com Subject: Review: Clear unwritten flag on during partial page truncation Message-ID: <20061220062813.GU44411608@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 10055 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 3699 Lines: 117 For a long time now we've been getting assert failures in XFSQA test 083 which is a fsstress test near ENOSPC. The failure mode is: <4>Assertion failed: !(iomapp->iomap_flags & IOMAP_DELAY), file: fs/xfs/linux-2.6/xfs_aops.c, line: 510 A inode read-write trace uncovered what the problem was. We had a page with an unwritten extent lying partially over it (last block on the page), and then we truncated the file to the first block on the page. Because it is a partial page truncation, we walk the buffers on the page and clear the flags on the buffers past end of file so that if we write to them again the correct flags are set on the buffers. block_invalidatepage() call discard_buffers() to do this, which clears all the common state from the buffers past EOF. The problem stems from the fact that the buffer_unwritten() flag is an XFS private flag, and hence does not get cleared from the buffer. If we then extend the file with a write to within the buffer that we failed to clear the unwritten flag from, we then make the wrong decision in xfs_convert_page_state() when trying to map that buffer - we see buffer_unwritten() instead of buffer_delay(), but the extent map we got for that range from xfs_bmapi() correctly says IOMAP_DELAY. Hence the solution is to clear the private buffer flags in xfs_vm_invalidatepage() so that when we extend the file the buffers on the page are all consistent. Patch below. Comments? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.6/xfs_aops.c | 38 +++++++++++++++++++++++++++++++++++++- 1 file changed, 37 insertions(+), 1 deletion(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_aops.c 2006-11-30 19:24:46.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c 2006-11-30 23:17:14.123674539 +1100 @@ -41,6 +41,8 @@ #include #include +STATIC void xfs_vm_invalidatepage(struct page *, unsigned long); + STATIC void xfs_count_page_state( struct page *page, @@ -1061,7 +1063,7 @@ error: */ if (err != -EAGAIN) { if (!unmapped) - block_invalidatepage(page, 0); + xfs_vm_invalidatepage(page, 0); ClearPageUptodate(page); } return err; @@ -1451,6 +1453,14 @@ xfs_vm_readpages( return mpage_readpages(mapping, pages, nr_pages, xfs_get_blocks); } +/* + * block_invalidatepage() doesn't clear private buffer flags like the unwritten + * flag. Leaving the unwritten flag behind on buffers that have been + * invalidated but are still attached to a page (i.e. buffer size < page size + * and partial page invalidation) will result in incorrect allocation occurring + * during writeback if the file is extended to within or past the invalidated + * block before writeback. + */ STATIC void xfs_vm_invalidatepage( struct page *page, @@ -1458,6 +1468,32 @@ xfs_vm_invalidatepage( { xfs_page_trace(XFS_INVALIDPAGE_ENTER, page->mapping->host, page, offset); + + /* + * Need to clear private flags from buffers on partial + * page truncations ourselves. Same inner loop as + * block_invalidatepage() is used. + */ + if (offset && page_has_buffers(page)) { + struct buffer_head *head, *bh, *next; + unsigned int curr_off = 0; + + head = page_buffers(page); + bh = head; + do { + unsigned int next_off = curr_off + bh->b_size; + next = bh->b_this_page; + + /* + * is this block fully invalidated? + */ + if (offset <= curr_off) + clear_buffer_unwritten(bh); + curr_off = next_off; + bh = next; + } while (bh != head); + } + block_invalidatepage(page, offset); } From owner-xfs@oss.sgi.com Wed Dec 20 00:22:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 00:22:53 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBK8Mmqw007660 for ; Wed, 20 Dec 2006 00:22:49 -0800 Received: from [134.15.160.9] (vpn-emea-sw-emea-160-9.emea.sgi.com [134.15.160.9]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kBK8Ltbj65891127; Wed, 20 Dec 2006 00:21:56 -0800 (PST) Message-ID: <4588F2A2.4000609@sgi.com> Date: Wed, 20 Dec 2006 08:21:54 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Clear unwritten flag on during partial page truncation References: <20061220062813.GU44411608@melbourne.sgi.com> In-Reply-To: <20061220062813.GU44411608@melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10056 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 809 Lines: 33 @@ -41,6 +41,8 @@ #include #include +STATIC void xfs_vm_invalidatepage(struct page *, unsigned long); + STATIC void xfs_count_page_state( struct page *page, @@ -1061,7 +1063,7 @@ error: */ if (err != -EAGAIN) { if (!unmapped) - block_invalidatepage(page, 0); + xfs_vm_invalidatepage(page, 0); We pass in an offset of zero here... @@ -1458,6 +1468,32 @@ xfs_vm_invalidatepage( { xfs_page_trace(XFS_INVALIDPAGE_ENTER, page->mapping->host, page, offset); + + /* + * Need to clear private flags from buffers on partial + * page truncations ourselves. Same inner loop as + * block_invalidatepage() is used. + */ + if (offset && page_has_buffers(page)) { And only do this code for non-zero offsets. Are you sure this is correct? From owner-xfs@oss.sgi.com Wed Dec 20 00:49:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 00:50:01 -0800 (PST) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBK8ntqw010648 for ; Wed, 20 Dec 2006 00:49:56 -0800 Received: from [134.15.160.9] (vpn-emea-sw-emea-160-9.emea.sgi.com [134.15.160.9]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kBK8RKqW73458109; Wed, 20 Dec 2006 00:27:21 -0800 (PST) Message-ID: <4588F8FD.9020602@sgi.com> Date: Wed, 20 Dec 2006 08:49:01 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Chinner CC: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Fix use after free on forced shutdown References: <20061219053012.GY33919298@melbourne.sgi.com> In-Reply-To: <20061219053012.GY33919298@melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10057 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 334 Lines: 15 Fix looks good to me. David Chinner wrote: > As found earlier today trying to reproduce a different use > after free, a machine with CONFIG_SLAB_DEBUG will panic on > a forced shutdown if the inode has an assocaited item > in the AIL. > > Trivial fix is to remove the item from the AIL before > freeing it. > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Wed Dec 20 01:08:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 01:08:19 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBK98Bqw013112 for ; Wed, 20 Dec 2006 01:08:13 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA15816; Wed, 20 Dec 2006 20:07:19 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBK97J7Y67760434; Wed, 20 Dec 2006 20:07:19 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBK97IWg67831058; Wed, 20 Dec 2006 20:07:18 +1100 (AEDT) Date: Wed, 20 Dec 2006 20:07:18 +1100 From: David Chinner To: Lachlan McIlroy Cc: David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Clear unwritten flag on during partial page truncation Message-ID: <20061220090718.GY44411608@melbourne.sgi.com> References: <20061220062813.GU44411608@melbourne.sgi.com> <4588F2A2.4000609@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4588F2A2.4000609@sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 10058 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1427 Lines: 51 On Wed, Dec 20, 2006 at 08:21:54AM +0000, Lachlan McIlroy wrote: > @@ -41,6 +41,8 @@ > #include > #include > > +STATIC void xfs_vm_invalidatepage(struct page *, unsigned long); > + > STATIC void > xfs_count_page_state( > struct page *page, > @@ -1061,7 +1063,7 @@ error: > */ > if (err != -EAGAIN) { > if (!unmapped) > - block_invalidatepage(page, 0); > + xfs_vm_invalidatepage(page, 0); > > We pass in an offset of zero here... Yup - to invalidate the whole page. > @@ -1458,6 +1468,32 @@ xfs_vm_invalidatepage( > { > xfs_page_trace(XFS_INVALIDPAGE_ENTER, > page->mapping->host, page, offset); > + > + /* > + * Need to clear private flags from buffers on partial > + * page truncations ourselves. Same inner loop as > + * block_invalidatepage() is used. > + */ > + if (offset && page_has_buffers(page)) { > > And only do this code for non-zero offsets. Are you sure this is correct? Yes. offset == 0 will currently just fall through to block_invalidatepage() which removes and frees all the buffers. Right now that first change is a no-op except on debug kernels we'll get a trace entry to indicate that we invalidated the page. In future, however, we may need to scan all the buffers before freeing them, so now we'll only need to modify xfs_vm_invalidatepage().... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 20 06:27:34 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 06:27:40 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBKERUqw029093 for ; Wed, 20 Dec 2006 06:27:32 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id BAA24328; Thu, 21 Dec 2006 01:26:37 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBKEQY7Y68362563; Thu, 21 Dec 2006 01:26:35 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBKEQV9568026983; Thu, 21 Dec 2006 01:26:31 +1100 (AEDT) Date: Thu, 21 Dec 2006 01:26:31 +1100 From: David Chinner To: Dmitriy Monakhov Cc: David Chinner , Dmitriy Monakhov , linux-kernel@vger.kernel.org, devel@openvz.org, Andrew Morton , xfs@oss.sgi.com Subject: Re: [PATCH] incorrect direct io error handling Message-ID: <20061220142631.GZ44411608@melbourne.sgi.com> References: <87d56he3tn.fsf@sw.ru> <20061218221515.GN44411608@melbourne.sgi.com> <87psagto4v.fsf@sw.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87psagto4v.fsf@sw.ru> User-Agent: Mutt/1.4.2.1i X-archive-position: 10059 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2997 Lines: 73 On Tue, Dec 19, 2006 at 09:07:12AM +0300, Dmitriy Monakhov wrote: > David Chinner writes: > > On Mon, Dec 18, 2006 at 04:22:44PM +0300, Dmitriy Monakhov wrote: > >> diff --git a/mm/filemap.c b/mm/filemap.c > >> index 8332c77..7c571dd 100644 > >> --- a/mm/filemap.c > >> +++ b/mm/filemap.c > > You comment in the first hunk that i_mutex may not be held here, > > but there's no comment in __generic_file_aio_write_nolock() that the > > i_mutex must be held for !S_ISBLK devices. > Any one may call directly call generic_file_direct_write() with i_mutex not held. Only block devices based on the implementation (i.e. buffered I/O is done here). but one can't call vmtruncate without the i_mutex held, so if a filesystem is calling generic_file_direct_write() it won't be able to use __generic_file_aio_write_nolock() without the i_mutex held (because it can right now if it doesn't need the buffered I/O fallback path), then > > > >> @@ -2341,6 +2353,13 @@ ssize_t generic_file_aio_write_nolock(st > >> ssize_t ret; > >> > >> BUG_ON(iocb->ki_pos != pos); > >> + /* > >> + * generic_file_buffered_write() may be called inside > >> + * __generic_file_aio_write_nolock() even in case of > >> + * O_DIRECT for non S_ISBLK files. So i_mutex must be held. > >> + */ > >> + if (!S_ISBLK(inode->i_mode)) > >> + BUG_ON(!mutex_is_locked(&inode->i_mutex)); > >> > >> ret = __generic_file_aio_write_nolock(iocb, iov, nr_segs, > >> &iocb->ki_pos); > > > > I note that you comment here in generic_file_aio_write_nolock(), > > but it's not immediately obvious that this is refering to the > > vmtruncate() call in __generic_file_aio_write_nolock(). > This is not about vmtruncate(). __generic_file_aio_write_nolock() may > call generic_file_buffered_write() even in case of O_DIRECT for !S_ISBLK, and No, the need for i_mutex is currently dependent on doing direct I/O and the return value from generic_file_buffered_write(). A filesystem that doesn't fall back to buffered I/O (e.g. XFS) can currently use generic_file_aio_write_nolock() without needing to hold i_mutex. Your change prevents that by introducing a vmtruncate() before the generic_file_buffered_write() return value check, which means that a filesystem now _must_ hold the i_mutex when calling generic_file_aio_write_nolock() even when it doesn't do buffered I/O through this path. > generic_file_buffered_write() has documented locking rules (i_mutex held). > IMHO it is important to explicitly document this . And after we realize > that i_mutex always held, vmtruncate() may be safely called. I don't think changing the locking semantics of generic_file_aio_write_nolock() to require a lock for all filesystem-based users is a good way to fix a filesystem specific direct I/O problem which can be easily fixed in filesystem specific code - i.e. call vmtruncate() in ext3_file_write() on failure.... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 20 07:45:58 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 07:46:01 -0800 (PST) Received: from mail.atipa.com (125.14.cm.sunflower.com [24.124.14.125]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBKFjuqw010469 for ; Wed, 20 Dec 2006 07:45:58 -0800 Received: from [192.168.100.199] ([192.168.100.199]) by mail.atipa.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 09:46:21 -0600 Message-ID: <45895A80.4010402@atipa.com> Date: Wed, 20 Dec 2006 09:45:04 -0600 From: Roger Heflin User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: David Chinner , xfs@oss.sgi.com Subject: Re: Issues with XFS on Sles9 sp2. References: <45704570.7020209@atipa.com> <20061203224832.GY37654165@melbourne.sgi.com> <457431B1.20700@atipa.com> <20061204224208.GO33919298@melbourne.sgi.com> <4574AA4F.4030902@atipa.com> <20061205004416.GU33919298@melbourne.sgi.com> In-Reply-To: <20061205004416.GU33919298@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2006 15:46:21.0984 (UTC) FILETIME=[FF6E2A00:01C7244D] X-archive-position: 10060 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: rheflin@atipa.com Precedence: bulk X-list: xfs Content-Length: 14449 Lines: 340 David, I have a bit more data on this hang up. So far we have not been able to reproduce it with any test other applications. It so far will only duplicate with one certain application and the trace from that application shows something interesting: acuSolve-gmpi D 00000000000493e0 0 14418 1 14419 16873 (NOTLB) Call Trace:{wait_on_page_writeback_range_wq+324} {__down+152} {default_wake_function+0} {__down_failed+53} {.text.lock.super+169} {do_sync+42} {sys_sync+62} {system_call+124} acuSolve-gmpi D 00000000000493e0 0 14419 1 18864 14418 (NOTLB) Call Trace:{__down+152} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_syncsub+2602} {:xfs:vfs_sync+40} {:xfs:linvfs_sync_super+68} {sync_filesystems+223} {do_sync+49} {sys_sync+62} {system_call+124} Both copies of the application appear to be calling sys_sync at the same time, and each one is hung in a different part of the sys_sync call, I wonder if there is a deadlock condition possible if one is doing this sort of thing? All other processes are always running on the machines, these 2 process are the extra ones that appear to be required to get the xfs lockup condition. Other application process have never reproduced the issue, so it is likely that something that these 2 processes are doing is required to cause the deadlock condition. Both processes are trying to get locks and failing, if I look at the other processes that are working with locks I see: Call Trace:{:xfs:kmem_zone_zalloc+50} {:xfs:_xfs_trans_alloc+36} {__down_write+117} {:xfs:xfs_ilock+93} {:xfs:xfs_syncsub+2787} {del_timer_sync+80} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_trans_getsb+106} {:xfs:xfs_trans_commit+332} {:xfs:xfs_trans_log_buf+107} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_trans_getsb+106} {:xfs:xfs_trans_commit+332} {:xfs:xfs_create+1359} {:xfs:linvfs_mknod+521} {:xfs:xfs_iunlock+102} {:xfs:xfs_lookup+119} {:xfs:linvfs_lookup+84} {real_lookup+123} {__down+152} {default_wake_function+0} {__down_failed+53} {.text.lock.super+169} {do_sync+42} {sys_sync+62} Call Trace:{__down+152} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_syncsub+2602} It very much looks like a deadlock as almost everyone hung looks to be working/waiting for locks. Is there a way to list the kernel locks and see who is holding what locks? Roger Full Trace follows: xfssyncd D 00000000000493e0 0 2760 1 3876 2755 (L-TLB) Call Trace:{:xfs:kmem_zone_zalloc+50} {:xfs:_xfs_trans_alloc+36} {__down_write+117} {:xfs:xfs_ilock+93} {:xfs:xfs_syncsub+2787} {del_timer_sync+80} {del_singleshot_timer_sync+21} {schedule_timeout+254} {:xfs:vfs_sync+40} {:xfs:vfs_sync_worker+25} {:xfs:xfssyncd+378} {:xfs:linvfs_fill_super+0} {child_rip+8} {:xfs:linvfs_fill_super+0} {:xfs:xfssyncd+0} {child_rip+0} res D 000000000000000a 0 16149 1 26319 16151 5825 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {__user_walk_it+70} {vfs_lstat+128} {do_page_fault+536} {sys_newlstat+31} {error_exit+0} {system_call+124} sbatchd D 00000000000493e0 0 16151 1 12686 16149 (NOTLB) Call Trace:{dput+33} {follow_mount+93} {dput+33} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {sys_chdir+138} {sys_select+1244} {system_call+124} gm_mapper D 000000000000000a 0 12686 1 16834 16151 (L-TLB) Call Trace:{:xfs:xfs_trans_log_buf+107} {__down+152} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_trans_getsb+106} {:xfs:xfs_trans_commit+332} {:xfs:xfs_free_extent+204} {:xfs:xfs_efd_init+68} {:xfs:kmem_zone_alloc+75} {:xfs:kmem_zone_zalloc+50} {:xfs:xfs_itruncate_finish+557} {:xfs:xfs_trans_alloc+217} {sysret_signal+28} {:xfs:xfs_inactive+591} {sysret_signal+28} {__pagevec_free+32} {sysret_signal+28} {:xfs:vn_rele+72} {:xfs:linvfs_clear_inode+18} {clear_inode+155} {generic_delete_inode+245} {iput+158} {dput+389} {__fput+270} {filp_close+126} {put_files_struct+115} {do_exit+1010} {__dequeue_signal+501} {sysret_signal+28} {do_group_exit+232} {get_signal_to_deliver+1175} {do_signal+1179} {do_signal+149} {:gm:gm_linux_ioctl+0} {:gm:gm_linux_ioctl+106} {sys_ioctl+1092} {sys_rt_sigreturn+653} {sysret_signal+28} {ptregscall_common+103} lim D 000000000000000a 0 16834 1 16835 17594 12686 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {__user_walk_it+70} {vfs_lstat+128} {save_i387+148} {do_signal+1501} {sys_newlstat+31} {sys_rt_sigaction+148} {system_call+124} pim D 00000000000493e0 0 16835 16834 16870 (NOTLB) Call Trace:{:xfs:xfs_buf_get_flags+877} {:xfs:kmem_zone_alloc+75} {__down+152} {default_wake_function+0} {:xfs:xfs_trans_log_buf+107} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_trans_getsb+106} {:xfs:xfs_trans_commit+332} {:xfs:xfs_dir2_createname+278} {:xfs:xfs_ichgtime+301} {:xfs:xfs_create+1359} {:xfs:linvfs_mknod+521} {:xfs:xfs_iunlock+102} {:xfs:xfs_lookup+119} {:xfs:linvfs_lookup+84} {real_lookup+123} {vfs_create+251} {open_namei+464} {filp_open+87} {sys_open+159} {sys_close+229} {system_call+124} elim.uptime D 00000000000493e0 0 16873 1 14418 18756 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+209} {filp_open+87} {sys_open+159} {error_exit+0} {system_call+124} res D 00000000000493e0 0 14323 16149 26319 (NOTLB) Call Trace:{inet_recvmsg+51} {sock_aio_read+346} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+175} {filp_open+87} {sys_open+159} {sys_socket+104} {system_call+124} acuSolve-gmpi D 00000000000493e0 0 14418 1 14419 16873 (NOTLB) Call Trace:{wait_on_page_writeback_range_wq+324} {__down+152} {default_wake_function+0} {__down_failed+53} {.text.lock.super+169} {do_sync+42} {sys_sync+62} {system_call+124} acuSolve-gmpi D 00000000000493e0 0 14419 1 18864 14418 (NOTLB) Call Trace:{__down+152} {default_wake_function+0} {__down_failed+53} {:xfs:.text.lock.xfs_buf+15} {:xfs:xfs_getsb+40} {:xfs:xfs_syncsub+2602} {:xfs:vfs_sync+40} {:xfs:linvfs_sync_super+68} {sync_filesystems+223} {do_sync+49} {sys_sync+62} {system_call+124} mktemp D 00000000000493e0 0 17594 1 17656 16834 (NOTLB) Call Trace:{SHATransform+25} {follow_mount+93} {dput+33} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {sys_mkdir+220} {system_call+124} check_EWNstag D 00000000000493e0 0 17620 1 17751 17656 (NOTLB) Call Trace:{do_sync_write+173} {__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+209} {filp_open+87} {sys_open+159} {error_exit+0} {system_call+124} sh D 00000000000493e0 0 17959 1 17793 17858 (NOTLB) Call Trace:{__down_read+125} {:xfs:xfs_access+44} {:xfs:linvfs_permission+20} {permission+55} {link_path_walk+348} {open_namei+209} {filp_open+87} {sys_open+159} {error_exit+0} {system_call+124} From owner-xfs@oss.sgi.com Wed Dec 20 08:04:05 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 08:04:10 -0800 (PST) Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBKG45qw012811 for ; Wed, 20 Dec 2006 08:04:05 -0800 Received: from [134.15.160.25] (vpn-emea-sw-emea-160-25.emea.sgi.com [134.15.160.25]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id kBKG38bj65955923; Wed, 20 Dec 2006 08:03:08 -0800 (PST) Message-ID: <45895EBA.8010208@sgi.com> Date: Wed, 20 Dec 2006 16:03:06 +0000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com Organization: SGI User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: nscott@aconex.com CC: Christoph Hellwig , bnaujok@sgi.com, xfs@oss.sgi.com, agruen@suse.de Subject: Re: [PATCH] rethink removal of xattr syscall stubs (for now) References: <1166490658.5572.89.camel@edge> <20061219100506.GA22779@infradead.org> <1166571069.5572.117.camel@edge> In-Reply-To: <1166571069.5572.117.camel@edge> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10061 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Content-Length: 635 Lines: 19 Nathan Scott wrote: > On Tue, 2006-12-19 at 10:05 +0000, Christoph Hellwig wrote: > | > Please apply as an interim fix to the original problem and to > | > the accidental new problems its caused, and I'll push through a > | > new patch in the new year. > | > | There is a way to re-export symbols you imported from another > | library with symbol versioning. That how for example libpthread > | works on recent Solaris versions. I'll find out how exactly that > | should be implemented. > > Ah, that sounds ideal - thanks! > Nathan, do you still need your patch applied or will you look into this new approach instead? Lachlan From owner-xfs@oss.sgi.com Wed Dec 20 10:42:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 10:42:06 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBKIfwqw005169 for ; Wed, 20 Dec 2006 10:42:00 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA09617; Fri, 24 Nov 2006 10:53:52 +1100 Message-Id: <200611232353.KAA09617@larry.melbourne.sgi.com> From: "Barry Naujok" To: "'Jonathan Groll'" , Subject: RE: Unexpected inode type 0160000 causes abort of xfs_repair Date: Fri, 24 Nov 2006 10:58:08 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AccPAUbEC40szw+9T+mfLcJp63ixbQAWdgKA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <20061123131405.GA27453@groll.co.za> X-archive-position: 10062 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 796 Lines: 23 Yes, this patch will be incorporated in the next xfsprogs update. And yes, it did blast the inode away, as it wasn't really an inode (or very very corrupted if it was). > -----Original Message----- > From: Jonathan Groll [mailto:lists@groll.co.za] > Sent: Friday, 24 November 2006 12:14 AM > To: Barry Naujok; xfs@oss.sgi.com > Subject: Re: Unexpected inode type 0160000 causes abort of xfs_repair > > On Thu, Nov 23, 2006 at 11:51:11AM +1100, Barry Naujok wrote: > > Can you try the attached patch and see how xfs_repair goes? > > Many thanks, the patch worked like a charm! Is it going to be > incorporated into the package in future? > > Luckily I didn't have to blast the inode away, but I suspect that is > exactly what the effect of the patch was ;-) > > Thanks again, > Jonathan From owner-xfs@oss.sgi.com Wed Dec 20 10:42:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 10:42:14 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBKIg4qw005191 for ; Wed, 20 Dec 2006 10:42:07 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09114; Thu, 23 Nov 2006 11:52:11 +1100 Message-Id: <200611230052.LAA09114@larry.melbourne.sgi.com> From: "Barry Naujok" To: "'Jonathan Groll'" Cc: Subject: Re: Unexpected inode type 0160000 causes abort of xfs_repair Date: Thu, 23 Nov 2006 11:55:35 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_1289_01C70EF6.496D6C00" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AccOdn7Sfd7USyITSO+ZuGEN3N7EwAAIlB9gAABMyQA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-archive-position: 10063 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 2187 Lines: 80 This is a multi-part message in MIME format. ------=_NextPart_000_1289_01C70EF6.496D6C00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Can you try the attached patch and see how xfs_repair goes? > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Jonathan Groll > Sent: Thursday, 23 November 2006 7:12 AM > To: xfs@oss.sgi.com > Subject: Unexpected inode type 0160000 causes abort of xfs_repair > > I'm unsuccesfully trying to repair an XFS filesystem > > xfs_repair /dev/md1 and the same with -L both end with > bad (negative) size -2150115811482766770 on inode 1539849750 > cleared inode 1539849750 > bad magic number 0x859b on inode 1539849751, resetting magic number > bad version number 0xffffff88 on inode 1539849751, resetting version > number > Unexpected inode type 0160000 inode 1539849751 > Aborted > > OS: debian sarge (stable) > Kernel: 2.6.15.7 > xfsprogs 2.8.11-1 > > Is there anything I can possibly do? > > Many thanks, > Jonathan Groll > > ------=_NextPart_000_1289_01C70EF6.496D6C00 Content-Type: application/octet-stream; name="xfs_repair.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="xfs_repair.diff" --- a/xfsprogs/repair/dinode.c 2006-11-23 11:47:17.000000000 +1100 +++ b/xfsprogs/repair/dinode.c 2006-11-23 11:40:31.219340329 +1100 @@ -2060,11 +2060,21 @@ type =3D XR_INO_FIFO; break; default: - type =3D XR_INO_UNKNOWN; - do_warn(_("Unexpected inode type %#o inode %llu\n"), - (int) (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT), lino); - abort(); - break; + retval++; + if (!verify_mode) { + do_warn(_("bad inode type %#o inode %llu\n"), + (int) (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT), lino); + if (!no_modify)=20=20 + *dirty +=3D clear_dinode(mp, dino, lino); + else=20 + *dirty =3D 1; + *cleared =3D 1; + *used =3D is_free; + } else if (!uncertain) { + do_warn(_("bad inode type %#o inode %llu\n"), + (int) (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT), lino); + } + return 1; } =20 /* ------=_NextPart_000_1289_01C70EF6.496D6C00-- From owner-xfs@oss.sgi.com Wed Dec 20 12:09:00 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 12:09:03 -0800 (PST) Received: from km12802.keymachine.de (ns.km12802.keymachine.de [62.141.52.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBKK8wqw014426 for ; Wed, 20 Dec 2006 12:09:00 -0800 Received: from km12802.keymachine.de (localhost [127.0.0.1]) by km12802.keymachine.de (8.12.11.20060308/8.12.11) with ESMTP id kBKJIeQU018557 for ; Wed, 20 Dec 2006 20:18:40 +0100 Received: (from nobody@localhost) by km12802.keymachine.de (8.12.11.20060308/8.12.11/Submit) id kBKJId4T018555; Wed, 20 Dec 2006 20:18:39 +0100 Date: Wed, 20 Dec 2006 20:18:39 +0100 Message-Id: <200612201918.kBKJId4T018555@km12802.keymachine.de> To: xfs@oss.sgi.com Subject: PART- TIME JOB OFFER FROM Mrs Sharon J Marvelous Art Works From: Mrs Sharon J Marvelous Reply-To: cyricustex@gmail.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 10064 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cyricustex@gmail.com Precedence: bulk X-list: xfs Content-Length: 1937 Lines: 20 Marvelous Art Works company 23 Haymarket, London,SW1Y 4DG Rc:122132 Hello, My name is Mrs Sharon J Marvelous and I am an artist. I live in United Kingdom, with my two kids,four cats, one dog and the love of my life. It is definitely a full house. I have been doing artwork since I was a little child. That gives me about 34 years of experience. I majored in art in high school and took a few college art courses. Most of my work is done in either pencil or airbrush mixed with color pencils. I have recently added designing and creating artwork on the computer.I have been selling my art for the last 3 years and have had my work featured on trading cards, prints and in magazines.I have sold in galleries and to private collectors from all around the world.I am always facing serious difficulties when it comes to selling my art works to my customers in the USA,they are always offering to pay with a money order,which is difficult for me to cash here in United Kingdom. I am looking for a representative in USA who will be working for me as a partime worker and i will be willing to pay 10% percent for every transaction,which wouldnt affect your present state of work,someone who would help me receive payments from my customers in your country.I mean someone that is responsible and reliable,because the cost of travelling and getting payments is very expensive,i am working on setting up a branch over there but that will take some time before i commence on that,so for now i need a representative there who will be handling the payment aspect for me who will receive payment on my behalf, cash them and send them to me before i release my artwork to the buyer, that will ease me the stress of travelling to cash each payment i get and it would also save me the cost of wasting money on travelling.If you are interested,kindly get back to me as soon as possible at cyricustex@gmail.com Regards, Mrs Sharon J Marvelous. From owner-xfs@oss.sgi.com Wed Dec 20 12:09:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 12:09:07 -0800 (PST) Received: from km12802.keymachine.de (ns.km12802.keymachine.de [62.141.52.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBKK8wr0014426 for ; Wed, 20 Dec 2006 12:09:02 -0800 Received: from km12802.keymachine.de (localhost [127.0.0.1]) by km12802.keymachine.de (8.12.11.20060308/8.12.11) with ESMTP id kBKJIwTb019188 for ; Wed, 20 Dec 2006 20:18:58 +0100 Received: (from nobody@localhost) by km12802.keymachine.de (8.12.11.20060308/8.12.11/Submit) id kBKJIwQ6019186; Wed, 20 Dec 2006 20:18:58 +0100 Date: Wed, 20 Dec 2006 20:18:58 +0100 Message-Id: <200612201918.kBKJIwQ6019186@km12802.keymachine.de> To: xfs@oss.sgi.com Subject: PART- TIME JOB OFFER FROM Mrs Sharon J Marvelous Art Works From: Mrs Sharon J Marvelous Reply-To: cyricustex@gmail.com MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-archive-position: 10065 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cyricustex@gmail.com Precedence: bulk X-list: xfs Content-Length: 1937 Lines: 20 Marvelous Art Works company 23 Haymarket, London,SW1Y 4DG Rc:122132 Hello, My name is Mrs Sharon J Marvelous and I am an artist. I live in United Kingdom, with my two kids,four cats, one dog and the love of my life. It is definitely a full house. I have been doing artwork since I was a little child. That gives me about 34 years of experience. I majored in art in high school and took a few college art courses. Most of my work is done in either pencil or airbrush mixed with color pencils. I have recently added designing and creating artwork on the computer.I have been selling my art for the last 3 years and have had my work featured on trading cards, prints and in magazines.I have sold in galleries and to private collectors from all around the world.I am always facing serious difficulties when it comes to selling my art works to my customers in the USA,they are always offering to pay with a money order,which is difficult for me to cash here in United Kingdom. I am looking for a representative in USA who will be working for me as a partime worker and i will be willing to pay 10% percent for every transaction,which wouldnt affect your present state of work,someone who would help me receive payments from my customers in your country.I mean someone that is responsible and reliable,because the cost of travelling and getting payments is very expensive,i am working on setting up a branch over there but that will take some time before i commence on that,so for now i need a representative there who will be handling the payment aspect for me who will receive payment on my behalf, cash them and send them to me before i release my artwork to the buyer, that will ease me the stress of travelling to cash each payment i get and it would also save me the cost of wasting money on travelling.If you are interested,kindly get back to me as soon as possible at cyricustex@gmail.com Regards, Mrs Sharon J Marvelous. From owner-xfs@oss.sgi.com Wed Dec 20 13:40:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 13:40:33 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBKLeQqw029236 for ; Wed, 20 Dec 2006 13:40:28 -0800 Received: from [192.168.5.76] (unknown [124.178.235.100]) by postoffice.aconex.com (Postfix) with ESMTP id 864DBAAC2F0; Thu, 21 Dec 2006 08:32:45 +1100 (EST) Subject: Re: [PATCH] rethink removal of xattr syscall stubs (for now) From: Nathan Scott Reply-To: nscott@aconex.com To: lachlan@sgi.com Cc: Christoph Hellwig , bnaujok@sgi.com, xfs@oss.sgi.com, agruen@suse.de In-Reply-To: <45895EBA.8010208@sgi.com> References: <1166490658.5572.89.camel@edge> <20061219100506.GA22779@infradead.org> <1166571069.5572.117.camel@edge> <45895EBA.8010208@sgi.com> Content-Type: text/plain Organization: Aconex Date: Thu, 21 Dec 2006 08:40:31 +1100 Message-Id: <1166650831.5572.164.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 10066 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 853 Lines: 27 On Wed, 2006-12-20 at 16:03 +0000, Lachlan McIlroy wrote: > Nathan Scott wrote: > > On Tue, 2006-12-19 at 10:05 +0000, Christoph Hellwig wrote: > > | > Please apply as an interim fix to the original problem and to > > | > the accidental new problems its caused, and I'll push through a > > | > new patch in the new year. > > | > > | There is a way to re-export symbols you imported from another > > | library with symbol versioning. That how for example libpthread > > | works on recent Solaris versions. I'll find out how exactly that > > | should be implemented. > > > > Ah, that sounds ideal - thanks! > > > > Nathan, do you still need your patch applied or will you look into > this new approach instead? > The patch needs to be applied, thanks. At a later date we'll fix it differently, but that will take some time. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Dec 20 15:47:11 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 15:47:16 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBKNl5qw009078 for ; Wed, 20 Dec 2006 15:47:09 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13712; Thu, 21 Dec 2006 10:46:06 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBKNk47Y66934023; Thu, 21 Dec 2006 10:46:04 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBKNk2Ev67500239; Thu, 21 Dec 2006 10:46:02 +1100 (AEDT) Date: Thu, 21 Dec 2006 10:46:02 +1100 From: David Chinner To: "Mr. Berkley Shands" Cc: linux-kernel@vger.kernel.org, Dave Lloyd , xfs@oss.sgi.com Subject: Re: 2.6.19 xfs crash spawns tcp reclen errors off nfs Message-ID: <20061220234602.GC44411608@melbourne.sgi.com> References: <4589A32A.7030802@exegy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4589A32A.7030802@exegy.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 10068 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 3965 Lines: 108 On Wed, Dec 20, 2006 at 02:55:06PM -0600, Mr. Berkley Shands wrote: > We have had several really strange NFS issues, reported out of > net/sunrpc/svcsock.c in > > static int > svc_tcp_recvfrom(struct svc_rqst *rqstp) > > svsk->sk_reclen &= 0x7fffffff; > dprintk("svc: TCP record, %d bytes\n", svsk->sk_reclen); > if (svsk->sk_reclen > serv->sv_bufsz) { > printk(KERN_NOTICE "RPC: bad TCP reclen 0x%08lx (large)\n", > (unsigned long) svsk->sk_reclen); > printk(KERN_NOTICE "sockaddr_in 0x%04x port 0x%04x max > 0x%08lx\n", > rqstp->rq_addr.sin_addr.s_addr, > rqstp->rq_addr.sin_port, (long) serv->sv_bufsz); > goto err_delete; > } > > The size reported grows, and grows, and... > > the server runs 2.6.19 when XFS has its issues (as follows) > 2TB partition, NFS exported. All machines are x86_64 AMD 275's with 16GB > and running redhat AS 4.4 (Centos 4.4) > > a typical crash under 2.6.19 is > > Dec 14 09:13:48 sanandreas kernel: Filesystem "sdb1": XFS internal error > xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller > 0xffffffff881ceaa8 Hmmmm - that is showing up up a lot more frequently in 2.6.18 and 2.6.19 that we've ever seen before. Kind of strange given we haven't changed anything the create transaction code for quite some time. However, a machine named "sanandreas" is bound to go kaboom at some point in time ;) > this then causes the heavy write clients to write garbage NFS request that > grow... XFS will be returning an EUCLEAN or EIO to indicate the filesystem has been shut down to all these write calls. Sounds like the clients aren't handling the errors properly.... > Neil Brown indicated that this NFS packet growth should have been fixed in > 2.6.18-rc5, but it still happens, easily triggered by the XFS shutdown. > the packet sizes reported can grow to > 1GB. > Dropping back to 2.6.18.1 stops the XFS crashing, and hence stops the > NFS mess. Do you have any idea of the workload that is triggering the XFS shutdown? We need more error reporting traps in the create transaction so we can track this down. As a first pass to narrowing down which code path is failing, can you run this quick patch - we should get an extra line in the kernel output just before the shutdown indicating what the error was and which branch returned it. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/xfs_vnodeops.c | 4 ++++ 1 file changed, 4 insertions(+) Index: 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/xfs_vnodeops.c 2006-12-12 12:05:21.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/xfs_vnodeops.c 2006-12-21 10:40:22.341657119 +1100 @@ -1932,6 +1932,7 @@ xfs_create( error = xfs_trans_reserve(tp, resblks, XFS_CREATE_LOG_RES(mp), 0, XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); if (error == ENOSPC) { + printk(KERN_WARNING "xfs_create: resv at enospc\n"); resblks = 0; error = xfs_trans_reserve(tp, 0, XFS_CREATE_LOG_RES(mp), 0, XFS_TRANS_PERM_LOG_RES, XFS_CREATE_LOG_COUNT); @@ -1962,6 +1963,7 @@ xfs_create( rdev, credp, prid, resblks > 0, &ip, &committed); if (error) { + printk(KERN_WARNING "xfs_create: dir_ialloc error %d\n", error); if (error == ENOSPC) goto error_return; goto abort_return; @@ -1991,6 +1993,7 @@ xfs_create( resblks - XFS_IALLOC_SPACE_RES(mp) : 0); if (error) { ASSERT(error != ENOSPC); + printk(KERN_WARNING "xfs_create: dir_createname error %d\n", error); goto abort_return; } xfs_ichgtime(dp, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); @@ -2025,6 +2028,7 @@ xfs_create( error = xfs_bmap_finish(&tp, &free_list, first_block, &committed); if (error) { xfs_bmap_cancel(&free_list); + printk(KERN_WARNING "xfs_create: xfs_bmap_finish error %d\n", error); goto abort_rele; } From owner-xfs@oss.sgi.com Wed Dec 20 15:46:08 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 15:46:14 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBKNk4qw008827 for ; Wed, 20 Dec 2006 15:46:07 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13553; Thu, 21 Dec 2006 10:44:53 +1100 Message-Id: <200612202344.KAA13553@larry.melbourne.sgi.com> From: "Barry Naujok" To: , Cc: "'Christoph Hellwig'" , , , Subject: RE: [PATCH] rethink removal of xattr syscall stubs (for now) Date: Thu, 21 Dec 2006 10:50:29 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <1166650831.5572.164.camel@edge> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acckf4tOyJTapNsgQ6Gid99G5oSsOQAEfxzA X-archive-position: 10067 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1257 Lines: 36 > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Nathan Scott > Sent: Thursday, 21 December 2006 8:41 AM > To: lachlan@sgi.com > Cc: Christoph Hellwig; bnaujok@sgi.com; xfs@oss.sgi.com; > agruen@suse.de > Subject: Re: [PATCH] rethink removal of xattr syscall stubs (for now) > > On Wed, 2006-12-20 at 16:03 +0000, Lachlan McIlroy wrote: > > Nathan Scott wrote: > > > On Tue, 2006-12-19 at 10:05 +0000, Christoph Hellwig wrote: > > > | > Please apply as an interim fix to the original problem and to > > > | > the accidental new problems its caused, and I'll push > through a > > > | > new patch in the new year. > > > | > > > | There is a way to re-export symbols you imported from another > > > | library with symbol versioning. That how for example libpthread > > > | works on recent Solaris versions. I'll find out how > exactly that > > > | should be implemented. > > > > > > Ah, that sounds ideal - thanks! > > > > > > > Nathan, do you still need your patch applied or will you look into > > this new approach instead? > > > > The patch needs to be applied, thanks. At a later date we'll fix it > differently, but that will take some time. I applied Nathan's patch yesterday. From owner-xfs@oss.sgi.com Wed Dec 20 16:12:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 16:12:45 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBL0Cbqw012750 for ; Wed, 20 Dec 2006 16:12:39 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14529; Thu, 21 Dec 2006 11:11:37 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBL0Ba7Y68511805; Thu, 21 Dec 2006 11:11:36 +1100 (AEDT) Received: (from bnaujok@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBL0BXSl68569165; Thu, 21 Dec 2006 11:11:33 +1100 (AEDT) Date: Thu, 21 Dec 2006 11:11:33 +1100 (AEDT) From: Barry Naujok Message-Id: <200612210011.kBL0BXSl68569165@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 958747 - attr2 corruption on Linux X-archive-position: 10069 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 983 Lines: 26 Fix attr2 corruption with btree data extents Date: Thu Dec 21 11:11:01 AEDT 2006 Workarea: snort.melbourne.sgi.com:/home/bnaujok/isms/linux-tot Inspected by: cattelan@thebarn.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27792a fs/xfs/xfs_attr_leaf.c - 1.105 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.105&r2=text&tr2=1.104&f=h - Lock forkoff when data extent is in btree form. Also allow more space for attr if extents must convert to btree form. fs/xfs/xfs_bmap.c - 1.360 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.360&r2=text&tr2=1.359&f=h - Lock forkoff when data extent is in btree form. fs/xfs/xfs_attr.c - 1.141 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.141&r2=text&tr2=1.140&f=h - Fix up initial creation of shortform attributes From owner-xfs@oss.sgi.com Wed Dec 20 20:02:51 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 20:02:55 -0800 (PST) Received: from amsfep17-int.chello.nl (amsfep17-int.chello.nl [62.179.120.12]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBL42mqw006654 for ; Wed, 20 Dec 2006 20:02:51 -0800 Received: from cable-213-132-153-91.upc.chello.be ([213.132.153.91]) by amsfep17-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20061221034235.NMSH8808.amsfep17-int.chello.nl@cable-213-132-153-91.upc.chello.be> for ; Thu, 21 Dec 2006 04:42:35 +0100 From: Grozdan Nikolov To: xfs@oss.sgi.com Subject: adding more redundancy in XFS? Date: Thu, 21 Dec 2006 04:42:32 +0100 User-Agent: KMail/1.9.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612210442.33706.microchip@chello.be> X-archive-position: 10070 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: microchip@chello.be Precedence: bulk X-list: xfs Content-Length: 1152 Lines: 25 Hi, I have a simple question regarding XFS. A while back ago I read a research paper about the IRON (Internal Robustness) of file systems that tests and compares various Linux file systems on how they handle data-integrity in case of a unclean unmount or power failure or even a disk failure. Though I'm not a file system guru like you guys I learned that XFS does a fairly good job but fails bad in specific areas, like, and I quote from the paper: "when an ordered data block write fails, XFS continues to log the failed transaction to the journal resulting in data corruption" The paper can be downloaded here: http://www.cs.wisc.edu/adsl/Publications/ (just click on the IRON file systems link for a PDF) My question is, is it possible to add to XFS more sanity checking (maybe even CRC checks?) on things like inodes, bitmaps, indirect pointers, etc to further improve the integrity of XFS? Thanks, GN -- Windows: a 64-bit service pack to a 32-bit extension and GUI shell to a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor and sold by a 2-bit company than can't stand 1-bit of competition From owner-xfs@oss.sgi.com Wed Dec 20 22:10:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 22:10:21 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBL6ACqw024862 for ; Wed, 20 Dec 2006 22:10:14 -0800 Received: from pcbnaujok (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA24334; Thu, 21 Dec 2006 17:09:19 +1100 Message-Id: <200612210609.RAA24334@larry.melbourne.sgi.com> From: "Barry Naujok" To: Cc: Subject: [PATCH] Return failure error if something fails in xfs_growfs Date: Thu, 21 Dec 2006 17:15:05 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_017F_01C72523.8FCA6E80" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: Acckx1tRNnSPht/YQCGnUuokZ3R2/w== X-archive-position: 10071 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 865 Lines: 31 This is a multi-part message in MIME format. ------=_NextPart_000_017F_01C72523.8FCA6E80 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit A very simple patch that return error rather than success if something fails in xfs_growfs. Barry. ------=_NextPart_000_017F_01C72523.8FCA6E80 Content-Type: application/octet-stream; name="growfs_error.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="growfs_error.diff" --- a/xfsprogs/growfs/xfs_growfs.c 2006-12-21 17:07:16.000000000 +1100 +++ b/xfsprogs/growfs/xfs_growfs.c 2006-12-21 17:06:16.639597863 +1100 @@ -448,5 +448,5 @@ if (geo.rtextsize !=3D ngeo.rtextsize) printf(_("realtime extent size changed from %d to %d\n"), geo.rtextsize, ngeo.rtextsize); - exit(0); + exit(error); } ------=_NextPart_000_017F_01C72523.8FCA6E80-- From owner-xfs@oss.sgi.com Wed Dec 20 22:16:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 22:16:57 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBL6Goqw026163 for ; Wed, 20 Dec 2006 22:16:53 -0800 Received: from edge (unknown [124.178.235.100]) by postoffice.aconex.com (Postfix) with ESMTP id 01E20AAC268; Thu, 21 Dec 2006 17:09:06 +1100 (EST) Subject: Re: Review: Clear unwritten flag on during partial page truncation From: Nathan Scott Reply-To: nscott@aconex.com To: David Chinner Cc: xfs-dev@sgi.com, xfs@oss.sgi.com In-Reply-To: <20061220062813.GU44411608@melbourne.sgi.com> References: <20061220062813.GU44411608@melbourne.sgi.com> Content-Type: text/plain Organization: Aconex Date: Thu, 21 Dec 2006 17:16:58 +1100 Message-Id: <1166681818.5572.190.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 10072 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 1263 Lines: 30 On Wed, 2006-12-20 at 17:28 +1100, David Chinner wrote: > Hence the solution is to clear the private buffer flags in > xfs_vm_invalidatepage() so that when we extend the file the buffers > on the page are all consistent. > > Patch below. Comments? Looks good Dave, nice sleuthing. In hindsight, it'd have been really good to have gone for the real BH_Unwritten flag upfront, and then being able to clear that inside discard_buffer (like was done for BH_Delay)... if we did that, then all this new code we're adding here (to just clear_buffer_unwritten, ultimately) and also the complete hack in xfs_count_page_state could be removed. It still might be worth considering doing that, in case there's other hard-to-hit-but-not-yet-uncovered bugs lurking along the same lines. But alot of effort, with the possibility of it not being merged at all, as it touches code outside XFS. D'oh. FWIW, GFS seems to have managed to do even worse here, and looks like they have dup'd big chunks of buffer.c ... has a discard_buffer() copy and invalidate_page and probably others which are closely derived from the equivalent buffer.c code ... guess those guys (hi Russell) could do some code rationalisation in this area too before they get bitten. cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Dec 20 22:21:38 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 22:21:42 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBL6Laqw027025 for ; Wed, 20 Dec 2006 22:21:37 -0800 Received: from edge (unknown [124.178.235.100]) by postoffice.aconex.com (Postfix) with ESMTP id 043DAAAC253; Thu, 21 Dec 2006 17:13:52 +1100 (EST) Subject: Re: [PATCH] Return failure error if something fails in xfs_growfs From: Nathan Scott Reply-To: nscott@aconex.com To: Barry Naujok Cc: xfs-dev@corp.sgi.com, xfs@oss.sgi.com In-Reply-To: <200612210609.RAA24334@larry.melbourne.sgi.com> References: <200612210609.RAA24334@larry.melbourne.sgi.com> Content-Type: text/plain Organization: Aconex Date: Thu, 21 Dec 2006 17:21:27 +1100 Message-Id: <1166682087.5572.192.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 10073 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 125 Lines: 10 On Thu, 2006-12-21 at 17:15 +1100, Barry Naujok wrote: > ... Makes sense & looks correct in xdiff. :) cheers. -- Nathan From owner-xfs@oss.sgi.com Wed Dec 20 22:37:27 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 22:37:31 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBL6bNqw028637 for ; Wed, 20 Dec 2006 22:37:25 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA25385; Thu, 21 Dec 2006 17:36:25 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBL6aN7Y69123910; Thu, 21 Dec 2006 17:36:24 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBL6aLQY69136449; Thu, 21 Dec 2006 17:36:21 +1100 (AEDT) Date: Thu, 21 Dec 2006 17:36:21 +1100 From: David Chinner To: Grozdan Nikolov Cc: xfs@oss.sgi.com Subject: Re: adding more redundancy in XFS? Message-ID: <20061221063621.GI33919298@melbourne.sgi.com> References: <200612210442.33706.microchip@chello.be> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612210442.33706.microchip@chello.be> User-Agent: Mutt/1.4.2.1i X-archive-position: 10074 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 2225 Lines: 55 On Thu, Dec 21, 2006 at 04:42:32AM +0100, Grozdan Nikolov wrote: > Hi, > > I have a simple question regarding XFS. A while back ago I read a research > paper about the IRON (Internal Robustness) of file systems that tests and > compares various Linux file systems on how they handle data-integrity in case > of a unclean unmount or power failure or even a disk failure. Though I'm not > a file system guru like you guys I learned that XFS does a fairly good job > but fails bad in specific areas, like, and I quote from the paper: "when an > ordered data block write fails, XFS continues to log the failed transaction > to the journal resulting in data corruption" XFS doesn't have an ordered journaling mode and I think their idea of a transaction is different to what XFS calls a transaction. > The paper can be downloaded here: http://www.cs.wisc.edu/adsl/Publications/ > (just click on the IRON file systems link for a PDF) Ok, I remember reading the preliminary paper that had the filesystem analysis about a year ago. I don't recall whether there was anything about XFS in it then. Quote section 3.1.4: "XFS supports only ordered journalling mode and data/writeback journaling modes are not present." According to the paper's definition of writeback/ordered/data journalling, XFS uses writeback journalling. i.e. there is no synchronisation between metadata logging and the data being written. That's a pretty bad mistake.... Also it is stated that the XFS analysis is only preliminary because XFS wasn't fully instrumented and so coverage of the fileystem was only partial. Hence it doesn't have the same error detection/recovery maps as the other filesystems so we've got no clear idea what tests those conclusions are based on. That being said, there's a lot of good stuff in that paper. Now all they've got to do is open source the tools they wrote and we can go and find and fix the problems their tool found.... > My question is, is it possible to add to XFS more sanity checking (maybe even > CRC checks?) on things like inodes, bitmaps, indirect pointers, etc to > further improve the integrity of XFS? Yes. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 20 23:42:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 20 Dec 2006 23:42:18 -0800 (PST) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBL7gBqw001825 for ; Wed, 20 Dec 2006 23:42:13 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GxIYJ-0004e7-0r for linux-xfs@oss.sgi.com; Thu, 21 Dec 2006 08:41:19 +0100 Received: from finn.gmane.org ([80.91.229.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Dec 2006 08:41:19 +0100 Received: from mszpak by finn.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Dec 2006 08:41:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: linux-xfs@oss.sgi.com From: =?ISO-8859-2?Q?Marcin_Zaj=B1czkowski?= Subject: Re: xfs_ncheck (actually xfs_db) eats a lot of memory and is killed Date: Thu, 21 Dec 2006 08:42:05 +0100 Message-ID: References: <200612200059.LAA04335@larry.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: finn.gmane.org User-Agent: Thunderbird 1.5.0.9 (X11/20061219) In-Reply-To: <200612200059.LAA04335@larry.melbourne.sgi.com> X-archive-position: 10075 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mszpak@wp.pl Precedence: bulk X-list: xfs Content-Length: 705 Lines: 21 Barry Naujok wrote: (...) >> Btw, is it possible to mount XFS filesystem from the file created by >> xfs_copy? >> If not, is it possible to restore file system "backuped" to file (by >> xfs_copy)? I read in the manual that the first parameter >> xfs_copy has to >> be device (not file). xfs_restore will work with that "dump"? > > Yes, you can mount an XFS filesystem file using the "-o loop" mount > option and specifying the file for the device. > > Yes, you can xfs_copy from a file back to a device. From the man page: > "The first (source) argument must be the pathname of the device or file > containing the XFS filesystem.". In fact. I don't know why I missed it earlier. Thanks Marcin From owner-xfs@oss.sgi.com Thu Dec 21 00:37:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 00:37:29 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBL8bHqw013226 for ; Thu, 21 Dec 2006 00:37:19 -0800 Received: from [134.14.55.84] (shark.melbourne.sgi.com [134.14.55.84]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA27875; Thu, 21 Dec 2006 19:16:24 +1100 Message-ID: <458A42D8.8090609@sgi.com> Date: Thu, 21 Dec 2006 19:16:24 +1100 From: Donald Douwsma User-Agent: Thunderbird 1.5.0.8 (X11/20060911) MIME-Version: 1.0 To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 957103 - Merge 2.6.x-xfs up to more recent kernels and new kdb versions X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10076 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Content-Length: 252342 Lines: 2979 Merge up to 2.6.19 Date: Thu Dec 21 18:59:09 AEDT 2006 Workarea: chook.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs-fresh Inspected by: chatz,donaldd The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27801a fs/xfs/support/debug.c - 1.36 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/debug.c.diff?r1=text&tr1=1.36&r2=text&tr2=1.35&f=h fs/xfs/Makefile-linux-2.6 - 1.206 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Makefile-linux-2.6.diff?r1=text&tr1=1.206&r2=text&tr2=1.205&f=h fs/xfs/linux-2.6/xfs_vfs.h - 1.67 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_vfs.h.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h fs/xfs/linux-2.6/xfs_buf.c - 1.233 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.233&r2=text&tr2=1.232&f=h fs/xfs/Kconfig - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/Kconfig.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h Modid: 2.6.x-xfs-melb:linux:27801b mainline-patches/linux-2.6/xfs_sysctl.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/linux-2.6/xfs_sysctl.c arch/mips/kernel/topology.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/topology.c arch/mips/tx4927/common/smsc_fdc37m81x.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/tx4927/common/smsc_fdc37m81x.c mainline-patches/linux-2.6/xfs_vfs.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/linux-2.6/xfs_vfs.c Documentation/DocBook/filesystems.tmpl - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/DocBook/filesystems.tmpl mainline-patches/xfs_vfsops.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/xfs_vfsops.c mainline-patches/xfs_iget.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/xfs_iget.c split-patches/kdb-v4.4-2.6.19-x86_64-2.bz2 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.19-x86_64-2.bz2 include/asm-arm/mach/udc_pxa2xx.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/mach/udc_pxa2xx.h mainline-patches/Kconfig - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/Kconfig mainline-patches/linux-2.6/xfs_vfs.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/linux-2.6/xfs_vfs.h mainline-patches/Makefile-linux-2.6 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/Makefile-linux-2.6 arch/mips/pci/pci-ev64120.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/pci/pci-ev64120.c split-patches/kdb-v4.4-2.6.19-ia64-2.bz2 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.19-ia64-2.bz2 mainline-patches/linux-2.6/xfs_globals.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/linux-2.6/xfs_globals.c mainline-patches/linux-2.6/xfs_linux.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/linux-2.6/xfs_linux.h arch/avr32/lib/io-readsb.S - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/lib/io-readsb.S arch/avr32/lib/io-writesb.S - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/lib/io-writesb.S arch/um/include/sysdep-i386/barrier.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/include/sysdep-i386/barrier.h split-patches/kdb-v4.4-2.6.19-i386-1.bz2 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.19-i386-1.bz2 split-patches/kdb-v4.4-2.6.19-common-1.bz2 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.19-common-1.bz2 arch/um/include/sysdep-x86_64/barrier.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/include/sysdep-x86_64/barrier.h arch/um/os-Linux/execvp.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/execvp.c mainline-patches/linux-2.6/xfs_sysctl.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/linux-2.6/xfs_sysctl.h mainline-patches/linux-2.6/xfs_super.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/linux-2.6/xfs_super.c mainline-patches/linux-2.6/xfs_super.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/linux-2.6/xfs_super.h include/asm-m68knommu/irq_regs.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m68knommu/irq_regs.h arch/mips/momentum/ocelot_c/platform.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_c/platform.c arch/ia64/pci/fixup.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/pci/fixup.c arch/mips/momentum/ocelot_3/platform.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_3/platform.c mainline-patches/xfs_acl.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/xfs_acl.c mainline-patches/xfs.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/xfs.h arch/arm/configs/realview-smp_defconfig - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/realview-smp_defconfig mainline-patches/linux-2.6/xfs_vnode.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/linux-2.6/xfs_vnode.h mainline-patches/quota/xfs_qm_bhv.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/quota/xfs_qm_bhv.c mainline-patches/xfs_behavior.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mainline-patches/xfs_behavior.h CREDITS - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/CREDITS.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h Documentation/DocBook/Makefile - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/DocBook/Makefile.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h Documentation/DocBook/journal-api.tmpl - 1.5 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/DocBook/journal-api.tmpl.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Documentation/DocBook/kernel-api.tmpl - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/DocBook/kernel-api.tmpl.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h Documentation/filesystems/udf.txt - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/filesystems/udf.txt.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Documentation/kernel-doc-nano-HOWTO.txt - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kernel-doc-nano-HOWTO.txt.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Documentation/kernel-parameters.txt - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kernel-parameters.txt.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h Documentation/mips/time.README - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/mips/time.README.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Documentation/power/interface.txt - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/power/interface.txt.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h Documentation/rtc.txt - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/rtc.txt.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Documentation/sound/alsa/ALSA-Configuration.txt - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/sound/alsa/ALSA-Configuration.txt.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h Documentation/usb/usb-serial.txt - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/usb/usb-serial.txt.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h MAINTAINERS - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/MAINTAINERS.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h Makefile - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Makefile.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h arch/alpha/kernel/srm_env.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/alpha/kernel/srm_env.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/alpha/kernel/vmlinux.lds.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/alpha/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/arm/Kconfig - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/Kconfig.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h arch/arm/Makefile - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/Makefile.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/arm/configs/assabet_defconfig - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/assabet_defconfig.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/configs/cerfcube_defconfig - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/cerfcube_defconfig.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/configs/h3600_defconfig - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/h3600_defconfig.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/arm/configs/integrator_defconfig - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/integrator_defconfig.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/configs/jornada720_defconfig - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/jornada720_defconfig.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/arm/configs/lart_defconfig - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/lart_defconfig.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/arm/configs/neponset_defconfig - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/neponset_defconfig.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/kernel/setup.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/setup.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/arm/kernel/time.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/time.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h arch/arm/kernel/vmlinux.lds.S - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/arm/mach-ebsa110/io.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-ebsa110/io.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/mach-sa1100/cpu-sa1110.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-sa1100/cpu-sa1110.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/mm/consistent.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/consistent.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/arm/mm/init.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/init.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/arm/mm/proc-xscale.S - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mm/proc-xscale.S.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/h8300/kernel/vmlinux.lds.S - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/h8300/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/i386/kernel/acpi/boot.c - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/acpi/boot.c.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h arch/i386/kernel/apm.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/apm.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/i386/kernel/entry.S - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/entry.S.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h arch/i386/kernel/io_apic.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/io_apic.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h arch/i386/kernel/microcode.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/microcode.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/i386/kernel/process.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/process.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h arch/i386/kernel/setup.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/setup.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h arch/i386/kernel/traps.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/traps.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h arch/i386/kernel/vmlinux.lds.S - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h arch/i386/mach-visws/visws_apic.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/mach-visws/visws_apic.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/i386/pci/common.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/pci/common.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/i386/pci/fixup.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/pci/fixup.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/i386/pci/i386.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/pci/i386.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/i386/pci/irq.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/pci/irq.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/i386/pci/pci.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/pci/pci.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ia64/Kconfig - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/Kconfig.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h arch/ia64/hp/sim/Kconfig - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/hp/sim/Kconfig.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ia64/hp/sim/hpsim_irq.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/hp/sim/hpsim_irq.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ia64/kernel/iosapic.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/iosapic.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h arch/ia64/kernel/irq.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/irq.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h arch/ia64/kernel/irq_ia64.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/irq_ia64.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/ia64/kernel/irq_lsapic.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/irq_lsapic.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ia64/kernel/sal.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/sal.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/ia64/kernel/setup.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/setup.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h arch/ia64/kernel/smp.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/smp.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h arch/ia64/kernel/vmlinux.lds.S - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h arch/ia64/mm/hugetlbpage.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/mm/hugetlbpage.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/ia64/pci/Makefile - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/pci/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/ia64/sn/kernel/bte.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/sn/kernel/bte.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/ia64/sn/kernel/irq.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/sn/kernel/irq.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/m68k/kernel/vmlinux-std.lds - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m68k/kernel/vmlinux-std.lds.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/m68k/kernel/vmlinux-sun3.lds - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m68k/kernel/vmlinux-sun3.lds.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/m68knommu/kernel/setup.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m68knommu/kernel/setup.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/m68knommu/kernel/time.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m68knommu/kernel/time.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/m68knommu/kernel/vmlinux.lds.S - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m68knommu/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/m68knommu/platform/5307/ints.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m68knommu/platform/5307/ints.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/Kconfig - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/Kconfig.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h arch/mips/Makefile - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/Makefile.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/mips/au1000/common/prom.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/au1000/common/prom.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/au1000/common/time.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/au1000/common/time.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/mips/dec/time.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/dec/time.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/mips/gt64120/momenco_ocelot/setup.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/gt64120/momenco_ocelot/setup.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/jmr3927/rbhma3100/irq.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/jmr3927/rbhma3100/irq.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/mips/jmr3927/rbhma3100/setup.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/jmr3927/rbhma3100/setup.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/kernel/Makefile - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/Makefile.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/mips/kernel/entry.S - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/entry.S.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/mips/kernel/head.S - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/head.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/kernel/irq.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/irq.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/mips/kernel/r4k_switch.S - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/r4k_switch.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/kernel/scall32-o32.S - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/scall32-o32.S.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/mips/kernel/scall64-64.S - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/scall64-64.S.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/mips/kernel/scall64-n32.S - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/scall64-n32.S.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/mips/kernel/scall64-o32.S - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/scall64-o32.S.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/mips/kernel/setup.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/setup.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/mips/kernel/smp.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/smp.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/mips/kernel/time.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/time.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/mips/kernel/traps.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/traps.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/mips/kernel/vmlinux.lds.S - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/mips/lib-64/dump_tlb.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/lib-64/dump_tlb.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/mips/mips-boards/generic/memory.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mips-boards/generic/memory.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/mips/mips-boards/generic/time.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mips-boards/generic/time.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/mips/mips-boards/malta/malta_setup.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mips-boards/malta/malta_setup.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/mm/c-sb1.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mm/c-sb1.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/mips/momentum/ocelot_c/Makefile - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_c/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/mips/momentum/ocelot_c/ocelot_c_fpga.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_c/ocelot_c_fpga.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/mips/momentum/ocelot_c/prom.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_c/prom.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/mips/momentum/ocelot_c/setup.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_c/setup.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/mips/momentum/ocelot_g/gt-irq.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_g/gt-irq.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/mips/momentum/ocelot_g/ocelot_pld.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_g/ocelot_pld.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/momentum/ocelot_g/setup.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_g/setup.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/mips/pci/Makefile - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/pci/Makefile.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/mips/sgi-ip27/ip27-irq.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/sgi-ip27/ip27-irq.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/mips/sgi-ip27/ip27-timer.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/sgi-ip27/ip27-timer.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/mips/sibyte/sb1250/time.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/sibyte/sb1250/time.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/tx4927/common/tx4927_setup.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/tx4927/common/tx4927_setup.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/parisc/kernel/vmlinux.lds.S - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/parisc/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/ppc/boot/simple/relocate.S - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/boot/simple/relocate.S.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ppc/kernel/misc.S - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/misc.S.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h arch/ppc/kernel/setup.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/setup.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h arch/ppc/kernel/traps.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/traps.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/ppc/kernel/vmlinux.lds.S - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/s390/Kconfig - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/Kconfig.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/s390/defconfig - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/defconfig.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h arch/s390/kernel/compat_linux.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/compat_linux.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h arch/s390/kernel/compat_signal.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/compat_signal.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/s390/kernel/compat_wrapper.S - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/compat_wrapper.S.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/s390/kernel/setup.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/setup.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h arch/s390/kernel/signal.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/signal.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/s390/kernel/traps.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/traps.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/s390/kernel/vmlinux.lds.S - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/s390/mm/init.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/mm/init.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/sh/boards/se/770x/irq.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/se/770x/irq.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/sh/boards/se/7751/irq.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/se/7751/irq.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sh/kernel/vmlinux.lds.S - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sparc/kernel/ebus.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/kernel/ebus.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sparc/kernel/entry.S - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/kernel/entry.S.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/sparc/kernel/systbls.S - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/kernel/systbls.S.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/sparc/kernel/vmlinux.lds.S - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/sparc64/kernel/central.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/central.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/kernel/ebus.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/ebus.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/sparc64/kernel/entry.S - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/entry.S.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/sparc64/kernel/isa.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/isa.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/kernel/pci_iommu.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/pci_iommu.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/sparc64/kernel/systbls.S - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/systbls.S.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h arch/sparc64/kernel/traps.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/traps.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/sparc64/kernel/vmlinux.lds.S - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/um/Makefile - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Makefile.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/um/Makefile-i386 - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Makefile-i386.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/um/drivers/mconsole_kern.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/drivers/mconsole_kern.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/um/drivers/mconsole_user.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/drivers/mconsole_user.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/um/drivers/ubd_kern.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/drivers/ubd_kern.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/um/include/mconsole.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/include/mconsole.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/um/include/mconsole_kern.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/include/mconsole_kern.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/um/include/os.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/include/os.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/um/kernel/tt/tracer.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/tt/tracer.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/um/os-Linux/Makefile - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/Makefile.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/um/os-Linux/process.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/process.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/v850/kernel/vmlinux.lds.S - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/v850/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/x86_64/Makefile - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/Makefile.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/x86_64/boot/setup.S - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/boot/setup.S.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/x86_64/ia32/ia32_signal.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/ia32/ia32_signal.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/x86_64/ia32/ptrace32.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/ia32/ptrace32.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/x86_64/kernel/e820.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/e820.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/x86_64/kernel/early_printk.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/early_printk.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/x86_64/kernel/io_apic.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/io_apic.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h arch/x86_64/kernel/process.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/process.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h arch/x86_64/kernel/smp.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/smp.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/x86_64/kernel/smpboot.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/smpboot.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h arch/x86_64/kernel/time.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/time.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h arch/x86_64/kernel/traps.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/traps.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h arch/x86_64/kernel/vmlinux.lds.S - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/x86_64/kernel/vsyscall.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/vsyscall.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/x86_64/mm/init.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/mm/init.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/acpi/osl.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/osl.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/atm/horizon.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/atm/horizon.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/base/Kconfig - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/base/Kconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/base/core.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/base/core.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/block/cciss.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/cciss.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h drivers/block/cpqarray.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/cpqarray.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/bluetooth/bluecard_cs.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/bluetooth/bluecard_cs.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/char/Kconfig - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/Kconfig.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h drivers/char/agp/generic.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/generic.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/char/agp/intel-agp.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/agp/intel-agp.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/char/drm/mga_drv.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/mga_drv.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/char/drm/radeon_state.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/radeon_state.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/char/ftape/zftape/zftape-buffers.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/ftape/zftape/zftape-buffers.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/ipmi/ipmi_msghandler.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/ipmi/ipmi_msghandler.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/char/isicom.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/isicom.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/char/watchdog/sc1200wdt.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/watchdog/sc1200wdt.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/cpufreq/Kconfig - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/cpufreq/Kconfig.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/cpufreq/cpufreq.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/cpufreq/cpufreq.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/fc4/fc.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/fc4/fc.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/fc4/fcp_impl.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/fc4/fcp_impl.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/i2c/busses/scx200_acb.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/i2c/busses/scx200_acb.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/ide/ide-cd.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/ide-cd.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h drivers/ide/legacy/hd.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/legacy/hd.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/ide/pci/amd74xx.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/amd74xx.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/ide/pci/generic.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/generic.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/ieee1394/eth1394.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ieee1394/eth1394.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/ieee1394/ohci1394.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ieee1394/ohci1394.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/isdn/hisax/Kconfig - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/hisax/Kconfig.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/isdn/hysdn/hysdn_sched.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/hysdn/hysdn_sched.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/md/dm-ioctl.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/dm-ioctl.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/md/dm.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/dm.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/md/md.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/md.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h drivers/md/multipath.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/multipath.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/md/raid1.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/raid1.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/md/raid5.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/raid5.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h drivers/media/common/saa7146_i2c.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/common/saa7146_i2c.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/media/dvb/dvb-core/dvb_frontend.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/dvb-core/dvb_frontend.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/media/dvb/frontends/Kconfig - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/Kconfig.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/media/dvb/frontends/mt312.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/mt312.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/media/dvb/frontends/nxt6000.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/nxt6000.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/media/dvb/ttpci/budget-ci.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/ttpci/budget-ci.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/media/dvb/ttpci/budget.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/ttpci/budget.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/media/video/Kconfig - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/Kconfig.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/media/video/saa7134/saa7134-cards.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa7134/saa7134-cards.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/message/fusion/mptbase.h - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/message/fusion/mptbase.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/misc/Kconfig - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/misc/Kconfig.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/mtd/chips/cfi_cmdset_0001.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/chips/cfi_cmdset_0001.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/net/Kconfig - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/Kconfig.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h drivers/net/arcnet/com20020.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/arcnet/com20020.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/au1000_eth.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/au1000_eth.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/net/b44.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/b44.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/net/bonding/bond_main.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/bonding/bond_main.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/net/e1000/e1000_ethtool.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/e1000/e1000_ethtool.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/net/e1000/e1000_hw.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/e1000/e1000_hw.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/net/e1000/e1000_main.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/e1000/e1000_main.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h drivers/net/hamradio/6pack.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/hamradio/6pack.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/net/r8169.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/r8169.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/net/tg3.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/tg3.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h drivers/net/tokenring/proteon.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/tokenring/proteon.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/net/tokenring/skisa.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/tokenring/skisa.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/net/wan/Kconfig - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wan/Kconfig.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/net/wan/n2.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wan/n2.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/pci/Kconfig - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/Kconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/pci/hotplug/acpiphp_glue.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/hotplug/acpiphp_glue.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/pci/pci-driver.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/pci-driver.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/pci/pci-sysfs.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/pci-sysfs.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/pci/quirks.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/quirks.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/pcmcia/au1000_generic.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/au1000_generic.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/pcmcia/ds.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/ds.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/pcmcia/i82092.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/i82092.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/pcmcia/yenta_socket.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/yenta_socket.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/s390/cio/css.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/css.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/s390/cio/device.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/device.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/s390/cio/device.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/cio/device.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/s390/scsi/zfcp_def.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/scsi/zfcp_def.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/s390/scsi/zfcp_scsi.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/scsi/zfcp_scsi.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/sbus/sbus.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/sbus/sbus.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/aic7xxx/aic79xx.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic79xx.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/scsi/aic7xxx/aic79xx_core.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic79xx_core.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/scsi/aic7xxx/aic79xx_inline.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic79xx_inline.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/aic7xxx/aic79xx_osm.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic79xx_osm.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/scsi/aic7xxx/aic79xx_osm.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic79xx_osm.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/scsi/aic7xxx/aic79xx_osm_pci.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic79xx_osm_pci.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/scsi/aic7xxx/aic79xx_pci.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic79xx_pci.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/scsi/aic7xxx/aic79xx_proc.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic79xx_proc.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/aic7xxx/aic7xxx.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic7xxx.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/aic7xxx/aic7xxx_core.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic7xxx_core.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/scsi/aic7xxx/aic7xxx_osm.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic7xxx_osm.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/scsi/aic7xxx/aic7xxx_osm.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic7xxx_osm.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/scsi/aic7xxx/aic7xxx_osm_pci.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic7xxx_osm_pci.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/scsi/aic7xxx/aic7xxx_pci.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic7xxx_pci.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/scsi/aic7xxx/aic7xxx_proc.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic7xxx_proc.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/aic7xxx_old.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx_old.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/scsi/dpt/dpti_i2o.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/dpt/dpti_i2o.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/fdomain.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/fdomain.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/scsi/gdth.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/gdth.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/scsi/imm.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/imm.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/scsi/pcmcia/nsp_cs.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/pcmcia/nsp_cs.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/scsi/pcmcia/nsp_cs.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/pcmcia/nsp_cs.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/scsi/pcmcia/nsp_debug.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/pcmcia/nsp_debug.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/pcmcia/nsp_message.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/pcmcia/nsp_message.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/ppa.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/ppa.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/scsi/psi240i.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/psi240i.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/psi240i.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/psi240i.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/qla1280.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla1280.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/scsi/scsi_debug.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_debug.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/scsi/scsi_lib.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_lib.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h drivers/scsi/scsi_scan.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_scan.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h drivers/scsi/scsi_sysfs.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_sysfs.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/scsi/sg.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/sg.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h drivers/scsi/st.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/st.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/scsi/sun3_NCR5380.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/sun3_NCR5380.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/sun3_scsi.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/sun3_scsi.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/sun3_scsi.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/sun3_scsi.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/sun3_scsi_vme.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/sun3_scsi_vme.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/tmscsim.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/tmscsim.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/telephony/ixj.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/telephony/ixj.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/usb/class/usblp.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/class/usblp.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/usb/core/hub.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/core/hub.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/usb/core/message.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/core/message.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/usb/host/ohci-hcd.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci-hcd.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h drivers/usb/host/ohci-hub.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci-hub.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/usb/input/hid-core.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/hid-core.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h drivers/usb/input/hid-input.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/hid-input.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/usb/input/hid.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/hid.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/usb/input/xpad.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/xpad.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/usb/misc/auerswald.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/misc/auerswald.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/usb/net/Kconfig - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/net/Kconfig.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/usb/net/usbnet.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/net/usbnet.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/usb/serial/Kconfig - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/Kconfig.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/usb/serial/ftdi_sio.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/ftdi_sio.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h drivers/usb/serial/ftdi_sio.h - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/ftdi_sio.h.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/usb/serial/ipaq.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/ipaq.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/usb/storage/unusual_devs.h - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/unusual_devs.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h drivers/video/aty/atyfb_base.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/aty/atyfb_base.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/video/offb.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/offb.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h fs/Kconfig - 1.32 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/Kconfig.diff?r1=text&tr1=1.32&r2=text&tr2=1.31&f=h fs/autofs/inode.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/autofs/inode.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/autofs/waitq.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/autofs/waitq.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/autofs4/inode.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/autofs4/inode.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h fs/autofs4/waitq.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/autofs4/waitq.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/block_dev.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/block_dev.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h fs/cifs/CHANGES - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/CHANGES.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h fs/cifs/connect.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/connect.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h fs/cifs/file.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/file.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h fs/cifs/inode.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/inode.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h fs/compat.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/compat.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h fs/dcache.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dcache.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h fs/fat/file.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/fat/file.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h fs/hfs/super.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hfs/super.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h fs/hugetlbfs/inode.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hugetlbfs/inode.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h fs/jbd/transaction.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jbd/transaction.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h fs/jfs/file.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jfs/file.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/jfs/xattr.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jfs/xattr.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h fs/lockd/svc.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/lockd/svc.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h fs/msdos/namei.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/msdos/namei.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h fs/nfsd/nfs3proc.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfsd/nfs3proc.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/nfsd/nfs4proc.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfsd/nfs4proc.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h fs/nfsd/vfs.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfsd/vfs.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h fs/proc/base.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/proc/base.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h fs/reiserfs/file.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/reiserfs/file.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h fs/reiserfs/super.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/reiserfs/super.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h fs/vfat/namei.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/vfat/namei.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h fs/xattr.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/xattr.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/asm-arm/arch-ebsa110/io.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-ebsa110/io.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-arm/arch-pxa/irqs.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-pxa/irqs.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-arm/arch-pxa/pxa-regs.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-pxa/pxa-regs.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/asm-arm/dma-mapping.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/dma-mapping.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/asm-arm/uaccess.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/uaccess.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/asm-generic/vmlinux.lds.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-generic/vmlinux.lds.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h include/asm-i386/acpi.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/acpi.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h include/asm-i386/io_apic.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/io_apic.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/asm-i386/mach-summit/mach_apic.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/mach-summit/mach_apic.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-i386/mach-visws/do_timer.h - 1.7 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/mach-visws/do_timer.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-i386/mach-visws/mach_apic.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/mach-visws/mach_apic.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ia64/sal.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/sal.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/asm-ia64/sn/addrs.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/sn/addrs.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/asm-ia64/uaccess.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/uaccess.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/asm-m68knommu/machdep.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m68knommu/machdep.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-mips/asm.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/asm.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-mips/div64.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/div64.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-mips/irq.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/irq.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/asm-mips/pgalloc.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/pgalloc.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-mips/pgtable-64.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/pgtable-64.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/asm-mips/sibyte/sb1250.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/sibyte/sb1250.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-mips/system.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/system.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h include/asm-mips/time.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/time.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-mips/unistd.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/unistd.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h include/asm-parisc/semaphore.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-parisc/semaphore.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-sh/irq.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-sh/irq.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h include/asm-sh/unistd.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-sh/unistd.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h include/asm-sparc/unistd.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-sparc/unistd.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h include/asm-sparc64/unistd.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-sparc64/unistd.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h include/asm-um/common.lds.S - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-um/common.lds.S.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-x86_64/acpi.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/acpi.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h include/asm-x86_64/hw_irq.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/hw_irq.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/asm-x86_64/io_apic.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/io_apic.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/asm-x86_64/pda.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/pda.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-x86_64/vsyscall.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/vsyscall.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/linux/compat.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/compat.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h include/linux/crypto.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/crypto.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/linux/hugetlb.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/hugetlb.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/linux/igmp.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/igmp.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/linux/in6.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/in6.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/linux/init.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/init.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/linux/ipmi_msgdefs.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ipmi_msgdefs.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/linux/ipx.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ipx.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/kernel.h - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/kernel.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h include/linux/libata.h - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/libata.h.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h include/linux/mmzone.h - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/mmzone.h.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h include/linux/msdos_fs.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/msdos_fs.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/linux/mtd/nand.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/mtd/nand.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/linux/netdevice.h - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/netdevice.h.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h include/linux/netfilter_arp/arp_tables.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/netfilter_arp/arp_tables.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/linux/netfilter_ipv4/ip_tables.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/netfilter_ipv4/ip_tables.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/linux/netfilter_ipv6/ip6_tables.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/netfilter_ipv6/ip6_tables.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h include/linux/nfsd/nfsd.h - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/nfsd/nfsd.h.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h include/linux/pagemap.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/pagemap.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h include/linux/pci_ids.h - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/pci_ids.h.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h include/linux/personality.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/personality.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/linux/pm.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/pm.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h include/linux/sched.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/sched.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h include/linux/spinlock.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/spinlock.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/linux/sysctl.h - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/sysctl.h.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h include/linux/ufs_fs.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ufs_fs.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/linux/vmalloc.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/vmalloc.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/linux/wait.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/wait.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/net/inet_ecn.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/inet_ecn.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/net/ip_vs.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/ip_vs.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/net/ipx.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/ipx.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/net/sock.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/sock.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h include/scsi/scsi.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/scsi/scsi.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h include/sound/version.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/sound/version.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h init/Kconfig - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/init/Kconfig.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h ipc/msg.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/ipc/msg.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h ipc/sem.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/ipc/sem.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h ipc/shm.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/ipc/shm.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h ipc/util.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/ipc/util.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h ipc/util.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/ipc/util.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h kernel/compat.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/compat.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h kernel/cpu.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/cpu.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h kernel/exit.c - 1.37 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/exit.c.diff?r1=text&tr1=1.37&r2=text&tr2=1.36&f=h kernel/fork.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/fork.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h kernel/futex.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/futex.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h kernel/kmod.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/kmod.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h kernel/module.c - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/module.c.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h kernel/power/disk.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/power/disk.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h kernel/printk.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/printk.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h kernel/signal.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/signal.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h kernel/sysctl.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/sysctl.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h kernel/user.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/user.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h kernel/workqueue.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/workqueue.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h lib/string.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/lib/string.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h mm/filemap.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/filemap.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h mm/mmap.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/mmap.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h mm/page_alloc.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/page_alloc.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h mm/readahead.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/readahead.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h mm/slab.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/slab.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h mm/vmalloc.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/vmalloc.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h mm/vmscan.c - 1.28 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/vmscan.c.diff?r1=text&tr1=1.28&r2=text&tr2=1.27&f=h net/Kconfig - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/Kconfig.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h net/appletalk/ddp.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/appletalk/ddp.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h net/bluetooth/hci_event.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bluetooth/hci_event.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h net/bluetooth/hci_sock.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bluetooth/hci_sock.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h net/bluetooth/l2cap.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bluetooth/l2cap.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h net/bluetooth/rfcomm/tty.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bluetooth/rfcomm/tty.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h net/bridge/br_ioctl.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/br_ioctl.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/bridge/netfilter/ebtables.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/netfilter/ebtables.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h net/core/pktgen.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/pktgen.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h net/core/skbuff.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/skbuff.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h net/core/sock.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/sock.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h net/decnet/af_decnet.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/decnet/af_decnet.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h net/decnet/dn_nsp_in.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/decnet/dn_nsp_in.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h net/decnet/dn_nsp_out.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/decnet/dn_nsp_out.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/decnet/dn_rules.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/decnet/dn_rules.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/ipv4/ip_options.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ip_options.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv4/ipconfig.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ipconfig.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h net/ipv4/ipvs/ip_vs_ftp.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ipvs/ip_vs_ftp.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ipv4/ipvs/ip_vs_proto_tcp.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ipvs/ip_vs_proto_tcp.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h net/ipv4/ipvs/ip_vs_proto_udp.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/ipvs/ip_vs_proto_udp.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ipv4/netfilter/arp_tables.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/arp_tables.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h net/ipv4/netfilter/ip_conntrack_core.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ip_conntrack_core.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h net/ipv4/netfilter/ip_queue.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ip_queue.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h net/ipv4/netfilter/ip_tables.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ip_tables.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h net/ipv4/netfilter/ipt_REJECT.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ipt_REJECT.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h net/ipv4/raw.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/raw.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h net/ipv4/sysctl_net_ipv4.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/sysctl_net_ipv4.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h net/ipv4/tcp.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h net/ipv4/udp.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/udp.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h net/ipv6/ip6_flowlabel.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/ip6_flowlabel.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h net/ipv6/ip6_tunnel.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/ip6_tunnel.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h net/ipv6/ndisc.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/ndisc.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h net/ipv6/netfilter/Kconfig - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/Kconfig.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h net/ipv6/netfilter/ip6_queue.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/ip6_queue.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h net/ipv6/netfilter/ip6_tables.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/ip6_tables.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h net/ipv6/netfilter/ip6t_ah.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/ip6t_ah.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/ipv6/netfilter/ip6t_frag.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/ip6t_frag.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv6/netfilter/ip6t_hbh.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/ip6t_hbh.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv6/netfilter/ip6t_rt.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/ip6t_rt.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv6/raw.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/raw.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h net/ipv6/route.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/route.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h net/ipv6/sit.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/sit.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h net/ipv6/udp.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/udp.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h net/ipx/af_ipx.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipx/af_ipx.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h net/ipx/ipx_proc.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipx/ipx_proc.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/ipx/ipx_route.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipx/ipx_route.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/irda/irlmp.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/irda/irlmp.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h net/netlink/af_netlink.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/netlink/af_netlink.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h net/sched/sch_htb.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sched/sch_htb.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h net/sctp/associola.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sctp/associola.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h net/sctp/endpointola.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sctp/endpointola.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h net/sctp/input.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sctp/input.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h net/sctp/protocol.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sctp/protocol.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h net/sctp/socket.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sctp/socket.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h net/sunrpc/svcauth.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sunrpc/svcauth.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h net/sunrpc/svcsock.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sunrpc/svcsock.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h net/xfrm/xfrm_state.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/xfrm/xfrm_state.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h net/xfrm/xfrm_user.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/xfrm/xfrm_user.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h scripts/kconfig/qconf.cc - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/scripts/kconfig/qconf.cc.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h security/selinux/hooks.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/security/selinux/hooks.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h security/selinux/ss/services.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/security/selinux/ss/services.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h sound/core/oss/pcm_oss.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/core/oss/pcm_oss.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h sound/core/pcm_native.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/core/pcm_native.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h sound/core/rtctimer.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/core/rtctimer.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h sound/pci/emu10k1/emu10k1_main.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/pci/emu10k1/emu10k1_main.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h sound/pci/intel8x0.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/pci/intel8x0.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h sound/usb/usbaudio.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/usb/usbaudio.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h usr/Makefile - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/usr/Makefile.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/ide/pci/sgiioc4.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/pci/sgiioc4.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/scsi/qla2xxx/qla_dbg.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla2xxx/qla_dbg.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/scsi/qla2xxx/qla_def.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla2xxx/qla_def.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/scsi/qla2xxx/qla_gbl.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla2xxx/qla_gbl.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/scsi/qla2xxx/qla_init.c - 1.22 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla2xxx/qla_init.c.diff?r1=text&tr1=1.22&r2=text&tr2=1.21&f=h drivers/scsi/qla2xxx/qla_isr.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla2xxx/qla_isr.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/scsi/qla2xxx/qla_os.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla2xxx/qla_os.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h drivers/scsi/qla2xxx/qla_version.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla2xxx/qla_version.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/usb/misc/emi62.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/misc/emi62.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/asm-arm/arch-pxa/udc.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-pxa/udc.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/saa7134/saa7134-input.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa7134/saa7134-input.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/md/mktables.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/mktables.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sh/drivers/dma/dma-sh.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/drivers/dma/dma-sh.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sh/boards/snapgear/setup.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/snapgear/setup.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/video/aty/radeon_i2c.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/aty/radeon_i2c.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h kdb/kdbmain.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdbmain.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h kdb/modules/kdbm_task.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/kdbm_task.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h include/linux/kdb.h - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/kdb.h.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h kdb/ChangeLog - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/ChangeLog.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h kdb/kdb_io.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdb_io.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h arch/i386/kdb/ChangeLog - 1.29 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/ChangeLog.diff?r1=text&tr1=1.29&r2=text&tr2=1.28&f=h arch/i386/kdb/kdba_io.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/kdba_io.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h drivers/net/e100.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/e100.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/net/irda/stir4200.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/irda/stir4200.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/md/dm-crypt.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/dm-crypt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/isdn/hisax/teles_cs.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/hisax/teles_cs.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/isdn/hisax/hisax_cfg.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/hisax/hisax_cfg.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/isdn/hisax/hfc_usb.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/hisax/hfc_usb.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/s390/appldata/appldata_base.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/s390/appldata/appldata_base.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h include/linux/sunrpc/svcauth_gss.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/sunrpc/svcauth_gss.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/i386/pci/mmconfig.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/pci/mmconfig.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h include/video/cvisionppc.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/video/cvisionppc.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/video/permedia2.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/video/permedia2.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/bluetooth/hci_sysfs.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bluetooth/hci_sysfs.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/mips/pmc-sierra/yosemite/smp.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/pmc-sierra/yosemite/smp.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/mips/pmc-sierra/yosemite/i2c-yosemite.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/pmc-sierra/yosemite/i2c-yosemite.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/pci/fixup-ev64120.c - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/pci/fixup-ev64120.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/mm/pg-r4k.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mm/pg-r4k.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/mips-boards/generic/pci.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mips-boards/generic/pci.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/mips/gt64120/ev64120/setup.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/gt64120/ev64120/setup.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/gt64120/common/time.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/gt64120/common/time.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/au1000/common/setup.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/au1000/common/setup.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/net/wireless/prism54/Makefile - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/prism54/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/input/keyboard/lkkbd.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/keyboard/lkkbd.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/serial/sh-sci.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/sh-sci.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/usb/input/ati_remote.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/ati_remote.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/x86_64/pci/mmconfig.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/pci/mmconfig.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h net/core/netpoll.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/netpoll.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h scripts/basic/docproc.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/scripts/basic/docproc.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h sound/pci/au88x0/au88x0_game.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/pci/au88x0/au88x0_game.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h split-patches/series - 1.41 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.41&r2=text&tr2=1.40&f=h arch/arm/common/dmabounce.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/common/dmabounce.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/arm/configs/bast_defconfig - 1.8 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/bast_defconfig.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/arm/configs/s3c2410_defconfig - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/s3c2410_defconfig.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/arm/configs/versatile_defconfig - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/versatile_defconfig.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/mach-lh7a40x/Kconfig - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-lh7a40x/Kconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/arm/oprofile/op_counter.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/oprofile/op_counter.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/char/ipmi/ipmi_si_intf.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/ipmi/ipmi_si_intf.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h drivers/net/s2io.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/s2io.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/serial/amba-pl010.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/amba-pl010.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/serial/amba-pl011.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/amba-pl011.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/usb/gadget/rndis.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/gadget/rndis.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/usb/gadget/rndis.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/gadget/rndis.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/asm-arm/arch-s3c2410/regs-clock.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-clock.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-arm/arch-s3c2410/regs-gpio.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-gpio.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h include/asm-arm/arch-s3c2410/regs-irq.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-irq.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-arm/arch-s3c2410/regs-lcd.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-lcd.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/asm-arm/arch-s3c2410/regs-timer.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-timer.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-arm/arch-s3c2410/regs-watchdog.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-watchdog.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h mm/hugetlb.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/hugetlb.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h net/bridge/br_sysfs_br.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/br_sysfs_br.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/i2c/busses/i2c-ixp4xx.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/i2c/busses/i2c-ixp4xx.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/mtd/maps/ixp4xx.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/ixp4xx.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/mtd/maps/wr_sbc82xx_flash.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/wr_sbc82xx_flash.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/pcmcia/pxa2xx_base.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/pxa2xx_base.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/pcmcia/pxa2xx_base.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/pxa2xx_base.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/pcmcia/pxa2xx_lubbock.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/pxa2xx_lubbock.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/pcmcia/soc_common.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/soc_common.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/scsi/qlogicfas408.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qlogicfas408.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/qlogicfas408.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qlogicfas408.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/arm/configs/ixp4xx_defconfig - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/ixp4xx_defconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/arm/configs/smdk2410_defconfig - 1.5 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/smdk2410_defconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/arm/mach-s3c2410/mach-smdk2410.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/mach-smdk2410.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/arm/mach-ixp4xx/common.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-ixp4xx/common.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/mtd/nand/toto.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/toto.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/mtd/nand/ppchameleonevb.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/ppchameleonevb.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/mtd/nand/nand_bbt.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/nand_bbt.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/mtd/nand/nand_base.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/nand_base.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/mtd/nand/diskonchip.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/diskonchip.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/mtd/nand/au1550nd.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/au1550nd.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/mtd/maps/sbc8240.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/sbc8240.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/mtd/maps/omap-toto-flash.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/omap-toto-flash.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/mtd/maps/mpc1211.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/mpc1211.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/mtd/maps/ichxrom.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/ichxrom.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/mtd/maps/dmv182.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/dmv182.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/mtd/devices/phram.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/devices/phram.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/mtd/chips/cfi_util.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/chips/cfi_util.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/pcmcia/pd6729.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/pd6729.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h scripts/mod/sumversion.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/scripts/mod/sumversion.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/scsi/3w-9xxx.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/3w-9xxx.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/scsi/3w-9xxx.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/3w-9xxx.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/serial/cpm_uart/cpm_uart.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/cpm_uart/cpm_uart.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/serial/cpm_uart/cpm_uart_core.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/cpm_uart/cpm_uart_core.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/serial/cpm_uart/cpm_uart_cpm1.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/cpm_uart/cpm_uart_cpm1.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/md/dm-raid1.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/dm-raid1.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h scripts/mod/modpost.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/scripts/mod/modpost.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h fs/jffs2/compr.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jffs2/compr.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/sched/sch_netem.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sched/sch_netem.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h net/ipv6/xfrm6_tunnel.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/xfrm6_tunnel.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/sh64/kernel/vmlinux.lds.S - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh64/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sh64/kernel/pcibios.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh64/kernel/pcibios.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/mtd/nftl-user.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/mtd/nftl-user.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/mtd/mtd-user.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/mtd/mtd-user.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/mtd/mtd-abi.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/mtd/mtd-abi.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/mtd/jffs2-user.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/mtd/jffs2-user.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/mtd/inftl-user.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/mtd/inftl-user.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/mach-s3c2410/gpio.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/gpio.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/linux/mtd/physmap.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/mtd/physmap.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sh/boards/se/7300/irq.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/se/7300/irq.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/arm/vfp/vfpdouble.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/vfp/vfpdouble.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/vfp/vfpmodule.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/vfp/vfpmodule.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/sh/boards/renesas/hs7751rvoip/setup.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/renesas/hs7751rvoip/setup.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h lib/Kconfig.debug - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/lib/Kconfig.debug.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h kernel/spinlock.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/spinlock.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/linux/mmc/protocol.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/mmc/protocol.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/asm-m32r/xor.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/xor.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/vga.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/vga.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/user.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/user.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/unistd.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/unistd.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/asm-m32r/unaligned.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/unaligned.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/types.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/types.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-m32r/timex.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/timex.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-m32r/termbits.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/termbits.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-m32r/syscall.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/syscall.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/string.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/string.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/stat.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/stat.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/sockios.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/sockios.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/smp.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/smp.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-m32r/signal.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/signal.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-m32r/siginfo.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/siginfo.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/sigcontext.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/sigcontext.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-m32r/shmparam.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/shmparam.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/shmbuf.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/shmbuf.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/sembuf.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/sembuf.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/segment.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/segment.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/scatterlist.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/scatterlist.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/rtc.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/rtc.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-m32r/posix_types.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/posix_types.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/pgalloc.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/pgalloc.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-m32r/pci.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/pci.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/param.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/param.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/opsput/opsput_pld.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/opsput/opsput_pld.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/opsput/opsput_lcd.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/opsput/opsput_lcd.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/opsput/opsput_lan.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/opsput/opsput_lan.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/namei.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/namei.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/msgbuf.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/msgbuf.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/module.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/module.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/m32700ut/m32700ut_pld.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/m32700ut/m32700ut_pld.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/m32700ut/m32700ut_lcd.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/m32700ut/m32700ut_lcd.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/m32700ut/m32700ut_lan.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/m32700ut/m32700ut_lan.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/ipcbuf.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/ipcbuf.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/ioctls.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/ioctls.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/ide.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/ide.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-m32r/errno.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/errno.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/dma.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/dma.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/delay.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/delay.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/current.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/current.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/arm/mach-ixp2000/ixdp2400.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-ixp2000/ixdp2400.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/asm-m32r/cache.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/cache.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-m32r/byteorder.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/byteorder.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/bugs.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/bugs.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-m32r/addrspace.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m32r/addrspace.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-arm/arch-s3c2410/regs-nand.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-nand.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/ibmvscsi/ibmvscsi.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/ibmvscsi/ibmvscsi.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/mtd/maps/ixp2000.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/ixp2000.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/mmc/mmc.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mmc/mmc.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/message/i2o/exec-osm.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/message/i2o/exec-osm.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/md/raid10.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/raid10.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/i386/kernel/kprobes.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/kprobes.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/um/kernel/uml.lds.S - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/uml.lds.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/um/kernel/dyn.lds.S - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/kernel/dyn.lds.S.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/m32r/opsput/dot.gdbinit - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/opsput/dot.gdbinit.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/oaks32r/dot.gdbinit.nommu - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/oaks32r/dot.gdbinit.nommu.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/mm/mmu.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/mm/mmu.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/m32r/mm/fault-nommu.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/mm/fault-nommu.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/mappi/dot.gdbinit.smp - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/mappi/dot.gdbinit.smp.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/mappi/dot.gdbinit.nommu - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/mappi/dot.gdbinit.nommu.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/mappi/dot.gdbinit - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/mappi/dot.gdbinit.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/m32700ut/dot.gdbinit_300MHz_32MB - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/m32700ut/dot.gdbinit_300MHz_32MB.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/m32700ut/dot.gdbinit_200MHz_16MB - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/m32700ut/dot.gdbinit_200MHz_16MB.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/lib/strlen.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/lib/strlen.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/m32r/lib/memset.S - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/lib/memset.S.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/lib/memcpy.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/lib/memcpy.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/m32r/lib/delay.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/lib/delay.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/m32r/lib/checksum.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/lib/checksum.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/m32r/kernel/head.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/head.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/m32r/kernel/vmlinux.lds.S - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/m32r/lib/ashxdi3.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/lib/ashxdi3.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/ia64/kernel/mca_drv.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/mca_drv.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/asm-arm/arch-s3c2410/regs-mem.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-s3c2410/regs-mem.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/media/dvb/frontends/l64781.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/l64781.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/media/dvb/frontends/dib3000.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/dib3000.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/media/dvb/frontends/cx24110.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/cx24110.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/media/dvb/frontends/cx22702.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/cx22702.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/media/dvb/frontends/cx22700.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/cx22700.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/frontends/mt352.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/mt352.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/media/dvb/frontends/sp8870.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/sp8870.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/frontends/sp887x.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/sp887x.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/frontends/stv0297.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/stv0297.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/media/dvb/frontends/stv0299.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/stv0299.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/media/dvb/frontends/tda10021.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/tda10021.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/media/dvb/frontends/tda1004x.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/tda1004x.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/media/dvb/frontends/tda8083.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/tda8083.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/frontends/ves1820.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/ves1820.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/media/dvb/frontends/ves1x93.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/ves1x93.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/video.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/video.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h scripts/gen_initramfs_list.sh - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/scripts/gen_initramfs_list.sh.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/um/Makefile-x86_64 - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/Makefile-x86_64.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/media/video/saa7134/saa7134-dvb.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa7134/saa7134-dvb.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/sh/boards/sh03/setup.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/sh03/setup.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/netfilter/ipt_hashlimit.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ipt_hashlimit.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/sh/boards/se/73180/irq.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/se/73180/irq.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h lib/reed_solomon/reed_solomon.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/lib/reed_solomon/reed_solomon.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h lib/reed_solomon/encode_rs.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/lib/reed_solomon/encode_rs.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h lib/reed_solomon/decode_rs.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/lib/reed_solomon/decode_rs.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/arm/configs/simpad_defconfig - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/simpad_defconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/mtd/maps/bast-flash.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/bast-flash.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/mtd/maps/ipaq-flash.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/ipaq-flash.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/momentum/ocelot_3/setup.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_3/setup.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/momentum/ocelot_3/prom.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_3/prom.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/mips/momentum/ocelot_3/ocelot_3_fpga.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_3/ocelot_3_fpga.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/momentum/ocelot_3/Makefile - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/momentum/ocelot_3/Makefile.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/mtd/maps/ts5500_flash.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/ts5500_flash.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/mips/mm/tlbex.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/mm/tlbex.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/mtd/nand/h1910.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/h1910.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/mtd/nand/rtc_from4.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/rtc_from4.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/mtd/nand/s3c2410.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/s3c2410.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/net/cris/eth_v10.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/cris/eth_v10.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/m32r/mappi2/dot.gdbinit.vdec2 - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/mappi2/dot.gdbinit.vdec2.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h kernel/sys_ni.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/sys_ni.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h kernel/irq/manage.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/irq/manage.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/pci/rom.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/rom.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h kernel/irq/handle.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/irq/handle.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/m32r/m32700ut/dot.gdbinit_400MHz_32MB - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/m32700ut/dot.gdbinit_400MHz_32MB.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/linux/rslib.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/rslib.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/scsi/aic7xxx/aic79xx_pci.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic79xx_pci.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/scsi/aic7xxx/aic7xxx_pci.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic7xxx/aic7xxx_pci.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/serial/crisv10.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/crisv10.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/usb/host/hc_crisv10.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/hc_crisv10.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h fs/cifs/readdir.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/readdir.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/video/intelfb/intelfbhw.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/intelfb/intelfbhw.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h arch/i386/kernel/acpi/earlyquirk.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/acpi/earlyquirk.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/infiniband/ulp/ipoib/ipoib_vlan.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/ipoib/ipoib_vlan.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/ulp/ipoib/ipoib_verbs.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/ipoib/ipoib_verbs.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/infiniband/ulp/ipoib/ipoib_multicast.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/ipoib/ipoib_multicast.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/infiniband/ulp/ipoib/ipoib_main.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/ipoib/ipoib_main.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/infiniband/ulp/ipoib/ipoib_ib.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/ipoib/ipoib_ib.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/infiniband/ulp/ipoib/ipoib_fs.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/ipoib/ipoib_fs.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/infiniband/ulp/ipoib/ipoib.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/ipoib/ipoib.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h Documentation/feature-removal-schedule.txt - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/feature-removal-schedule.txt.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/mtd/maps/sharpsl-flash.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/sharpsl-flash.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/um/os-Linux/signal.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/signal.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/net/sk98lin/skethtool.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/sk98lin/skethtool.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/mtd/devices/block2mtd.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/devices/block2mtd.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/infiniband/hw/mthca/mthca_reset.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_reset.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/infiniband/hw/mthca/mthca_qp.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_qp.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/infiniband/hw/mthca/mthca_provider.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_provider.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/hw/mthca/mthca_provider.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_provider.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/acpi/processor_core.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/processor_core.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/acpi/processor_perflib.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/processor_perflib.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/scsi/scsi_transport_iscsi.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/scsi/scsi_transport_iscsi.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/arm/configs/omap_h2_1610_defconfig - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/omap_h2_1610_defconfig.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/block/aoe/aoeblk.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/block/aoe/aoeblk.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/arm/kernel/smp.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/smp.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/mtd/maps/walnut.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/walnut.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/infiniband/hw/mthca/mthca_profile.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_profile.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/media/video/tveeprom.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/tveeprom.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/infiniband/hw/mthca/mthca_profile.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_profile.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/infiniband/hw/mthca/mthca_pd.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_pd.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/infiniband/hw/mthca/mthca_mr.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_mr.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/mtd/nand/nandsim.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/nandsim.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/infiniband/hw/mthca/mthca_memfree.h - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_memfree.h.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h include/linux/mtd/xip.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/mtd/xip.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/linux/if_infiniband.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/if_infiniband.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/char/drm/drm_bufs.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/drm_bufs.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/mtd/nand/sharpsl.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/sharpsl.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/infiniband/hw/mthca/mthca_memfree.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_memfree.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/char/drm/drm_sysfs.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/drm_sysfs.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/infiniband/hw/mthca/mthca_mcg.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_mcg.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/infiniband/hw/mthca/mthca_main.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_main.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/infiniband/hw/mthca/mthca_mad.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_mad.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/infiniband/hw/mthca/mthca_eq.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_eq.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/infiniband/hw/mthca/mthca_doorbell.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_doorbell.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/infiniband/hw/mthca/mthca_dev.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_dev.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/infiniband/hw/mthca/mthca_cq.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_cq.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/infiniband/hw/mthca/mthca_config_reg.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_config_reg.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/infiniband/hw/mthca/mthca_cmd.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_cmd.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/hw/mthca/mthca_cmd.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_cmd.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/infiniband/hw/mthca/mthca_av.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_av.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/infiniband/hw/mthca/mthca_allocator.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_allocator.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/infiniband/core/verbs.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/verbs.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/infiniband/core/user_mad.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/user_mad.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/infiniband/core/ud_header.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/ud_header.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/infiniband/core/sysfs.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/sysfs.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/infiniband/core/smi.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/smi.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/infiniband/core/smi.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/smi.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/infiniband/core/sa_query.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/sa_query.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/core/packer.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/packer.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/infiniband/core/mad_priv.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/mad_priv.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/core/mad.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/mad.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/infiniband/core/fmr_pool.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/fmr_pool.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/infiniband/core/device.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/device.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/infiniband/core/core_priv.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/core_priv.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/infiniband/core/cache.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/cache.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/infiniband/core/agent.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/agent.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/infiniband/core/agent.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/agent.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/frv/kernel/vmlinux.lds.S - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/frv/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/scsi_transport_iscsi.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_transport_iscsi.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/serial/mpsc.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/mpsc.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/video/backlight/corgi_bl.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/backlight/corgi_bl.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/debugfs/inode.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/debugfs/inode.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/isdn/hisax/hfc_usb.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/hisax/hfc_usb.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/isdn/hisax/hfc4s8s_l1.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/hisax/hfc4s8s_l1.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/isdn/hisax/hfc4s8s_l1.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/hisax/hfc4s8s_l1.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/infiniband/hw/mthca/mthca_uar.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_uar.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/md/dm-round-robin.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/dm-round-robin.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h sound/pci/hda/patch_realtek.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/pci/hda/patch_realtek.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h sound/pci/hda/hda_intel.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/pci/hda/hda_intel.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/media/dvb/b2c2/flexcop-usb.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/b2c2/flexcop-usb.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/media/dvb/frontends/or51132.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/or51132.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/frontends/or51211.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/or51211.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/cx88/cx88-input.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/cx88/cx88-input.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h net/ipv4/multipath_wrandom.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/multipath_wrandom.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/ipv4/multipath_rr.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/multipath_rr.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/multipath_random.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/multipath_random.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/multipath_drr.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/multipath_drr.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/video/nvidia/nvidia.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/nvidia/nvidia.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/video/nvidia/nv_type.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/nvidia/nv_type.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/video/nvidia/nv_setup.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/nvidia/nv_setup.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/video/nvidia/nv_hw.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/nvidia/nv_hw.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/scsi/lpfc/lpfc_attr.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/lpfc/lpfc_attr.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/scsi/lpfc/lpfc_ct.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/lpfc/lpfc_ct.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/scsi/lpfc/lpfc_hbadisc.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/lpfc/lpfc_hbadisc.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/usb/serial/cp2101.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/cp2101.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/scsi/lpfc/lpfc_sli.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/lpfc/lpfc_sli.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/scsi/qla2xxx/qla_attr.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla2xxx/qla_attr.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/serial/ioc4_serial.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/ioc4_serial.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/ia64/kdb/kdbasupport.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdbasupport.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/ia64/kdb/kdba_io.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdba_io.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h arch/ia64/kdb/ChangeLog - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/ChangeLog.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h include/asm-cris/arch-v10/io_interface_mux.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v10/io_interface_mux.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h sound/pci/hda/patch_sigmatel.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/pci/hda/patch_sigmatel.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-arm/mtd-xip.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/mtd-xip.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-arm/arch-sa1100/mtd-xip.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-sa1100/mtd-xip.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-arm/arch-pxa/mtd-xip.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-pxa/mtd-xip.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h Documentation/kprobes.txt - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kprobes.txt.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-cris/arch-v32/hwregs/asm/ata_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/ata_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/bif_core_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/bif_core_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/base/dd.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/base/dd.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ipv4/tcp_htcp.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_htcp.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/ipv4/tcp_cong.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_cong.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/ipv4/fib_trie.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/fib_trie.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/asm-cris/arch-v32/hwregs/asm/bif_dma_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/bif_dma_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/nfsd/nfs4recover.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfsd/nfs4recover.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h mm/sparse.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/sparse.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-cris/arch-v32/hwregs/asm/bif_slave_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/bif_slave_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/config_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/config_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/mtd/plat-ram.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/mtd/plat-ram.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/cris_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/cris_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/acpi/hotkey.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/hotkey.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-xtensa/xtensa/config-linux_be/specreg.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-xtensa/xtensa/config-linux_be/specreg.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/ide/cris/ide-cris.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ide/cris/ide-cris.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/infiniband/core/cm.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/cm.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/core/mad_rmpp.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/mad_rmpp.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/infiniband/core/mad_rmpp.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/mad_rmpp.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/pcmcia/pcmcia_resource.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/pcmcia_resource.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/pcmcia/pcmcia_ioctl.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/pcmcia_ioctl.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/infiniband/core/ucm.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/ucm.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/infiniband/core/uverbs.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/uverbs.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/core/uverbs_cmd.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/uverbs_cmd.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/core/uverbs_main.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/uverbs_main.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/core/uverbs_mem.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/uverbs_mem.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/cris/arch-v10/kernel/dma.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v10/kernel/dma.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/dma_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/dma_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v10/kernel/io_interface_mux.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v10/kernel/io_interface_mux.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/eth_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/eth_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/dvb-usb/Kconfig - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/dvb-usb/Kconfig.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/cris/arch-v32/boot/compressed/README - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/boot/compressed/README.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/boot/compressed/misc.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/boot/compressed/misc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/boot/rescue/head.S - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/boot/rescue/head.S.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/drivers/cryptocop.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/drivers/cryptocop.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/cris/arch-v32/drivers/gpio.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/drivers/gpio.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/drivers/i2c.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/drivers/i2c.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/drivers/iop_fw_load.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/drivers/iop_fw_load.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/drivers/nandflash.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/drivers/nandflash.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/cris/arch-v32/drivers/pcf8563.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/drivers/pcf8563.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/cris/arch-v32/kernel/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/kernel/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/kernel/fasttimer.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/kernel/fasttimer.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/kernel/time.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/kernel/time.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/kernel/vcs_hook.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/kernel/vcs_hook.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/kernel/vcs_hook.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/kernel/vcs_hook.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/lib/dram_init.S - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/lib/dram_init.S.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/cris/arch-v32/lib/hw_settings.S - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/cris/arch-v32/lib/hw_settings.S.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/xtensa/platform-iss/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/xtensa/platform-iss/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/xtensa/kernel/vmlinux.lds.S - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/xtensa/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-cris/arch-v32/hwregs/asm/gio_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/gio_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/intr_vect_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/intr_vect_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/irq_nmi_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/irq_nmi_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/marb_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/marb_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/mmu_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/mmu_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/frontends/bcm3510.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/bcm3510.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/dvb/frontends/lgdt330x.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/lgdt330x.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-cris/arch-v32/hwregs/asm/pinmux_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/pinmux_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/frontends/s5h1420.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/s5h1420.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/skge.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/skge.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/message/fusion/mptfc.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/message/fusion/mptfc.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-cris/arch-v32/hwregs/asm/reg_map_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/reg_map_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/mtd/maps/alchemy-flash.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/alchemy-flash.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/mtd/maps/mainstone-flash.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/mainstone-flash.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/mtd/maps/plat-ram.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/plat-ram.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/um/sys-x86_64/unmap.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/sys-x86_64/unmap.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-cris/arch-v32/hwregs/asm/rt_trace_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/rt_trace_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/ser_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/ser_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/sser_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/sser_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/um/sys-i386/unmap.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/sys-i386/unmap.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-cris/arch-v32/hwregs/asm/strcop_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/strcop_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/strmux_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/strmux_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/asm/timer_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/asm/timer_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/ata_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/ata_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/bif_core_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/bif_core_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/bif_dma_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/bif_dma_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/bif_slave_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/bif_slave_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/config_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/config_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/dma.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/dma.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/dma_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/dma_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/eth_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/eth_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/extmem_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/extmem_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/gio_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/gio_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/m32r/mappi3/dot.gdbinit - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/m32r/mappi3/dot.gdbinit.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/intr_vect_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/intr_vect_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_crc_par_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_crc_par_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_dmc_in_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_dmc_in_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_dmc_out_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_dmc_out_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_in_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_in_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_in_extra_defs_asm.h - 1.4 - http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_in_extra_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h changed include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_out_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_out_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_out_extra_defs_asm.h - 1.4 - http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_fifo_out_extra_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h changed include/asm-cris/arch-v32/hwregs/iop/asm/iop_mpu_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_mpu_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_sap_in_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sap_in_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_sap_out_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sap_out_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_scrc_in_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_scrc_in_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_scrc_out_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_scrc_out_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_spu_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_spu_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_cfg_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_cfg_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_cpu_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_cpu_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_mpu_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_mpu_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_spu_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_sw_spu_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_timer_grp_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_timer_grp_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_trigger_grp_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_trigger_grp_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/asm/iop_version_defs_asm.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/asm/iop_version_defs_asm.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_crc_par_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_crc_par_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_dmc_in_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_dmc_in_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_dmc_out_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_dmc_out_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_fifo_in_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_fifo_in_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_fifo_in_extra_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_fifo_in_extra_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_fifo_out_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_fifo_out_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_fifo_out_extra_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_fifo_out_extra_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_mpu_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_mpu_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_sap_in_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_sap_in_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_sap_out_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_sap_out_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_scrc_in_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_scrc_in_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_scrc_out_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_scrc_out_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_spu_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_spu_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_sw_cfg_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_sw_cfg_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_sw_cpu_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_sw_cpu_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_sw_mpu_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_sw_mpu_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_sw_spu_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_sw_spu_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_timer_grp_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_timer_grp_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_trigger_grp_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_trigger_grp_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/iop/iop_version_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/iop/iop_version_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/irq_nmi_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/irq_nmi_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/marb_bp_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/marb_bp_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/marb_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/marb_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/pinmux_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/pinmux_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/reg_map.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/reg_map.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/reg_rdwr.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/reg_rdwr.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/rt_trace_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/rt_trace_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/ser_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/ser_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/sser_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/sser_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/strcop.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/strcop.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/timer_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/timer_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/strcop_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/strcop_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-cris/arch-v32/hwregs/strmux_defs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-cris/arch-v32/hwregs/strmux_defs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h .gitignore - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/.gitignore.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/ieee80211/ieee80211_rx.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ieee80211/ieee80211_rx.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h net/ipv4/inet_diag.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/inet_diag.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ieee80211/Kconfig - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ieee80211/Kconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-powerpc/topology.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/topology.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-powerpc/timex.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/timex.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/dccp/options.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/options.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/dccp/ipv4.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/ipv4.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/dccp/input.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/input.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/dccp/dccp.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/dccp.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/dccp/ccids/ccid3.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/ccids/ccid3.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/dccp/ccids/Kconfig - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/ccids/Kconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/ipv4/netfilter/ip_conntrack_netlink.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ip_conntrack_netlink.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/dccp/ackvec.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/ackvec.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/dccp/ackvec.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/ackvec.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/arm/configs/collie_defconfig - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/collie_defconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/arm/configs/corgi_defconfig - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/corgi_defconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/arm/configs/spitz_defconfig - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/spitz_defconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/dccp/Kconfig - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/Kconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/drm/r300_cmdbuf.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/r300_cmdbuf.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/pcmcia/omap_cf.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/omap_cf.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/wireless/hostap/hostap_plx.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/hostap/hostap_plx.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/drm/savage_bci.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/savage_bci.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/wireless/hostap/hostap_cs.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/hostap/hostap_cs.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/linux/pci_regs.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/pci_regs.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/char/drm/savage_state.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/savage_state.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/chelsio/suni1x10gexp_regs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/suni1x10gexp_regs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/chelsio/subr.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/subr.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/chelsio/sge.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/sge.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/chelsio/sge.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/sge.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/net/chelsio/regs.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/regs.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/chelsio/pm3393.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/pm3393.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/chelsio/mv88x201x.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/mv88x201x.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/firmware/dell_rbu.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/firmware/dell_rbu.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/net/chelsio/gmac.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/gmac.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-sparc64/futex.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-sparc64/futex.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/chelsio/espi.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/espi.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/chelsio/espi.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/espi.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/net/chelsio/elmer0.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/elmer0.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/chelsio/cxgb2.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/cxgb2.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/chelsio/cpl5_cmd.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/cpl5_cmd.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/chelsio/cphy.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/cphy.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/fuse/file.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/fuse/file.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/fuse/dir.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/fuse/dir.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/net/chelsio/common.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/chelsio/common.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/cassini.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/cassini.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/i2c/busses/i2c-pxa.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/i2c/busses/i2c-pxa.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/mips/kernel/asm-offsets.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/asm-offsets.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/netfilter/nfnetlink_log.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/netfilter/nfnetlink_log.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/netfilter/nfnetlink_queue.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/netfilter/nfnetlink_queue.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/hw/mthca/mthca_srq.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_srq.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/infiniband/hw/mthca/mthca_wqe.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_wqe.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/rdma/ib_verbs.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_verbs.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/rdma/ib_user_verbs.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_user_verbs.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/rdma/ib_user_mad.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_user_mad.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/rdma/ib_user_cm.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_user_cm.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/rdma/ib_smi.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_smi.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/rdma/ib_sa.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_sa.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/rdma/ib_pack.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_pack.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/rdma/ib_mad.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_mad.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/rdma/ib_fmr_pool.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_fmr_pool.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/rdma/ib_cm.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_cm.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/rdma/ib_cache.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_cache.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/spinlock_api_smp.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/spinlock_api_smp.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h scripts/kconfig/.gitignore - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/scripts/kconfig/.gitignore.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/saa6588.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa6588.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/infiniband/hw/mthca/mthca_catas.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/mthca/mthca_catas.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/infiniband/ulp/srp/ib_srp.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/srp/ib_srp.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/infiniband/ulp/srp/ib_srp.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/srp/ib_srp.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/char/tlclk.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/tlclk.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h block/scsi_ioctl.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/scsi_ioctl.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h block/ll_rw_blk.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/ll_rw_blk.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/netfilter/nf_conntrack_core.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/netfilter/nf_conntrack_core.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h block/cfq-iosched.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/cfq-iosched.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/scsi/srp.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/scsi/srp.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/um/os-Linux/helper.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/helper.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/macintosh/windfarm_pm81.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/macintosh/windfarm_pm81.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/macintosh/windfarm_pm91.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/macintosh/windfarm_pm91.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/frontends/nxt200x.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/nxt200x.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/video/saa7115.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa7115.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/mtd/maps/mtx-1_flash.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/mtx-1_flash.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/sysdev/i8259.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/sysdev/i8259.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/sysdev/dart.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/sysdev/dart.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/platforms/pseries/iommu.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/pseries/iommu.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-powerpc/unistd.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/unistd.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/asm-powerpc/time.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/time.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-powerpc/tce.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/tce.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-powerpc/system.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/system.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-powerpc/reg.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/reg.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-powerpc/prom.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/prom.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/powerpc/platforms/powermac/sleep.S - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/powermac/sleep.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-powerpc/ppc_asm.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/ppc_asm.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-powerpc/pmc.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/pmc.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-powerpc/oprofile_impl.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/oprofile_impl.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/platforms/iseries/setup.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/iseries/setup.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-powerpc/iommu.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/iommu.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-powerpc/io.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/io.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-powerpc/i8259.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/i8259.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/platforms/iseries/iommu.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/iseries/iommu.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-powerpc/firmware.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/firmware.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-powerpc/current.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/current.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-powerpc/cputable.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/cputable.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/powerpc/platforms/chrp/setup.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/chrp/setup.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-powerpc/asm-compat.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/asm-compat.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/oprofile/op_model_rs64.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/oprofile/op_model_rs64.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/oprofile/op_model_power4.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/oprofile/op_model_power4.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/oprofile/op_model_fsl_booke.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/oprofile/op_model_fsl_booke.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/oprofile/common.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/oprofile/common.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/oprofile/Makefile - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/oprofile/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/mm/hugetlbpage.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/mm/hugetlbpage.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/powerpc/mm/hash_low_32.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/mm/hash_low_32.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/lib/sstep.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/lib/sstep.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-mips/mipsmtregs.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/mipsmtregs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/kernel/vmlinux.lds.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/kernel/vio.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/vio.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/powerpc/kernel/vdso64/vdso64.lds.S - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/vdso64/vdso64.lds.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/kernel/vdso64/gettimeofday.S - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/vdso64/gettimeofday.S.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/kernel/vdso32/vdso32.lds.S - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/vdso32/vdso32.lds.S.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/kernel/vdso.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/vdso.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/asm-mips/mach-au1x00/au1xxx_ide.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-mips/mach-au1x00/au1xxx_ide.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-m68knommu/irqnode.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-m68knommu/irqnode.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/kernel/traps.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/traps.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/powerpc/kernel/time.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/time.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/powerpc/kernel/setup_64.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/setup_64.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/powerpc/kernel/setup_32.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/setup_32.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/powerpc/kernel/rtas_flash.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/rtas_flash.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/kernel/prom.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/prom.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/powerpc/kernel/pmc.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/pmc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/jffs2/summary.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jffs2/summary.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/jffs2/summary.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jffs2/summary.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/jffs2/debug.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jffs2/debug.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/jffs2/debug.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jffs2/debug.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/kernel/module_64.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/module_64.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/kernel/misc_64.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/misc_64.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/kernel/misc_32.S - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/misc_32.S.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/scsi/iscsi_tcp.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/iscsi_tcp.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/pcmcia/m8xx_pcmcia.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/m8xx_pcmcia.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/kernel/iommu.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/iommu.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/powerpc/kernel/head_64.S - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/head_64.S.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/powerpc/kernel/cputable.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/cputable.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/powerpc/kernel/btext.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/btext.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/kernel/Makefile - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/powerpc/configs/cell_defconfig - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/configs/cell_defconfig.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/powerpc/boot/Makefile - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/boot/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/Kconfig - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/Kconfig.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/mtd/rfd_ftl.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/rfd_ftl.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/mips/tx4938/toshiba_rbtx4938/spi_txx9.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/tx4938/toshiba_rbtx4938/spi_txx9.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/mips/sibyte/bcm1480/time.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/sibyte/bcm1480/time.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/philips/pnx8550/common/time.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/philips/pnx8550/common/time.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/mips/oprofile/op_model_mipsxx.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/oprofile/op_model_mipsxx.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/spi/spi.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/spi/spi.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/oprofile/op_model_7450.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/oprofile/op_model_7450.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h scripts/kconfig/lxdialog/util.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/scripts/kconfig/lxdialog/util.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/message/fusion/lsi/mpi_log_fc.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/message/fusion/lsi/mpi_log_fc.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/media/dvb/frontends/cx24123.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/cx24123.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/nfs/sysctl.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfs/sysctl.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/tipc/port.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/tipc/port.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/powerpc/platforms/cell/spu_base.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/cell/spu_base.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/platforms/cell/spufs/file.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/cell/spufs/file.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/powerpc/platforms/cell/spufs/hw_ops.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/cell/spufs/hw_ops.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/netfilter/xt_realm.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/netfilter/xt_realm.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/netfilter/nf_conntrack_netlink.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/netfilter/nf_conntrack_netlink.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h net/ipv4/tcp_cubic.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_cubic.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/dccp/ipv6.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/ipv6.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/linux/netfilter/x_tables.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/netfilter/x_tables.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/sky2.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/sky2.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/char/synclink_gt.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/synclink_gt.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sh/kernel/cpu/irq/ipr.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/kernel/cpu/irq/ipr.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/sh/kernel/cpu/irq/pint.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/kernel/cpu/irq/pint.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/sysdev/ipic.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/sysdev/ipic.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/sysdev/dart_iommu.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/sysdev/dart_iommu.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/edac/amd76x_edac.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/edac/amd76x_edac.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/video/backlight/hp680_bl.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/backlight/hp680_bl.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h arch/um/os-Linux/skas/process.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/skas/process.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/edac/i82875p_edac.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/edac/i82875p_edac.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/edac/Kconfig - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/edac/Kconfig.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/edac/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/edac/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/edac/e752x_edac.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/edac/e752x_edac.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/edac/e7xxx_edac.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/edac/e7xxx_edac.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/edac/edac_mc.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/edac/edac_mc.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/edac/edac_mc.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/edac/edac_mc.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/edac/r82600_edac.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/edac/r82600_edac.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/parport/parport_ip32.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/parport/parport_ip32.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/arm/mach-s3c2410/s3c2410-gpio.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-s3c2410/s3c2410-gpio.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/macintosh/windfarm_pm112.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/macintosh/windfarm_pm112.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/um/os-Linux/sys-i386/tls.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/sys-i386/tls.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h Documentation/memory-barriers.txt - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/memory-barriers.txt.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h net/ipv4/netfilter/ip_conntrack_helper_h323.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/ip_conntrack_helper_h323.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h fs/splice.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/splice.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h Documentation/video4linux/README.cpia2 - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/video4linux/README.cpia2.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/kernel/perfmon_fsl_booke.c - 1.4 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/perfmon_fsl_booke.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/powerpc/kernel/module_32.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/module_32.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/dccp/ccids/ccid2.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/ccids/ccid2.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/infiniband/hw/ipath/Kconfig - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ipath/Kconfig.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/infiniband/hw/ipath/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ipath/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/infiniband/hw/ipath/ipath_driver.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ipath/ipath_driver.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/w1/masters/matrox_w1.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/w1/masters/matrox_w1.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/input/usbtouchscreen.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/usbtouchscreen.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/rtc/rtc-test.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/rtc/rtc-test.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/rtc/rtc-rs5c372.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/rtc/rtc-rs5c372.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/rtc/rtc-dev.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/rtc/rtc-dev.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/rtc/interface.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/rtc/interface.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/infiniband/hw/ipath/ipath_intr.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ipath/ipath_intr.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/infiniband/hw/ipath/ipath_kernel.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ipath/ipath_kernel.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h mm/migrate.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/migrate.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/x86_64/kdb/kdbasupport.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kdb/kdbasupport.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/x86_64/kdb/kdba_io.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kdb/kdba_io.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/pcmcia/at91_cf.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pcmcia/at91_cf.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/wireless/bcm43xx/bcm43xx_main.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/bcm43xx/bcm43xx_main.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/net/wireless/bcm43xx/bcm43xx_leds.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/bcm43xx/bcm43xx_leds.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/wireless/bcm43xx/bcm43xx_leds.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/bcm43xx/bcm43xx_leds.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/x86_64/kdb/ChangeLog - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kdb/ChangeLog.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/wireless/bcm43xx/bcm43xx_dma.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/bcm43xx/bcm43xx_dma.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/isdn/gigaset/common.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/isdn/gigaset/common.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/um/os-Linux/tls.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/tls.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/dvb/frontends/zl10353.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/zl10353.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/kernel/smtc.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/smtc.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/kernel/smtc-asm.S - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/smtc-asm.S.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/mips/kernel/smp-mt.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/kernel/smp-mt.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/dvb/frontends/lnbp21.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/lnbp21.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/video/bt8xx/bttv-cards.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/bt8xx/bttv-cards.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/video/dabusb.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/dabusb.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/gigaset_dev.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/gigaset_dev.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/video/sn9c102/sn9c102_core.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/sn9c102/sn9c102_core.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h drivers/media/video/et61x251/et61x251_core.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/et61x251/et61x251_core.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h Documentation/accounting/getdelays.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/accounting/getdelays.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/jffs2/jffs2_fs_sb.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jffs2/jffs2_fs_sb.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/jffs2/jffs2_fs_i.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jffs2/jffs2_fs_i.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/infiniband/ulp/iser/iser_verbs.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/iser/iser_verbs.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/infiniband/ulp/iser/iser_memory.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/iser/iser_memory.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/infiniband/ulp/iser/iser_initiator.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/iser/iser_initiator.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/infiniband/ulp/iser/iscsi_iser.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/iser/iscsi_iser.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h fs/cifs/sess.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/cifs/sess.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/infiniband/ulp/iser/iscsi_iser.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/ulp/iser/iscsi_iser.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/video/pnx4008/sdum.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/pnx4008/sdum.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/video/pnx4008/pnxrgbfb.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/pnx4008/pnxrgbfb.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-powerpc/systbl.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-powerpc/systbl.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/usb/serial/sierra.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/serial/sierra.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/linux/taskstats_kern.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/taskstats_kern.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Documentation/video4linux/README.pvrusb2 - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/video4linux/README.pvrusb2.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/asm-arm/arch-lh7a40x/ssp.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-arm/arch-lh7a40x/ssp.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/infiniband/core/cma.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/cma.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/infiniband/core/addr.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/core/addr.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/sysdev/tsi108_dev.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/sysdev/tsi108_dev.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc/kernel/of_device.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/kernel/of_device.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/rdma/ib_addr.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/rdma/ib_addr.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h include/scsi/libiscsi.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/scsi/libiscsi.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/arm/configs/ateb9200_defconfig - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/configs/ateb9200_defconfig.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/platforms/83xx/mpc834x_itx.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/83xx/mpc834x_itx.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/delayacct.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/delayacct.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/dvb/frontends/isl6421.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/isl6421.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/irq/chip.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/irq/chip.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/lockdep.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/lockdep.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/kernel/of_device.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/of_device.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/taskstats.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/taskstats.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h kernel/unwind.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/unwind.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/sparc64/kernel/prom.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/prom.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/scsi/libiscsi.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/libiscsi.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/rtc/rtc-ds1553.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/rtc/rtc-ds1553.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/rtc/rtc-at91.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/rtc/rtc-at91.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/arm/mach-lh7a40x/lcd-panel.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-lh7a40x/lcd-panel.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/arm/mach-pnx4008/core.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-pnx4008/core.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/video/pvrusb2/pvrusb2-audio.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-audio.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-audio.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-audio.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-context.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-context.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-context.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-context.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-ctrl.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-ctrl.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-ctrl.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-ctrl.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-cx2584x-v4l.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-debug.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-debug.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-debugifc.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-debugifc.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-debugifc.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-debugifc.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-eeprom.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-eeprom.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-eeprom.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-eeprom.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h mm/vmstat.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/vmstat.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-encoder.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-encoder.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-encoder.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-encoder.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-hdw.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-hdw.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-hdw.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-hdw.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-i2c-chips-v4l2.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-i2c-chips-v4l2.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/sbs.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/sbs.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-i2c-cmd-v4l2.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-i2c-cmd-v4l2.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-i2c-cmd-v4l2.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-i2c-cmd-v4l2.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-i2c-core.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-i2c-core.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-i2c-core.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-io.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-io.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-io.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-io.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-ioread.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-ioread.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-ioread.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-ioread.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-main.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-main.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-std.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-std.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-std.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-std.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-sysfs.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-sysfs.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-sysfs.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-sysfs.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-tuner.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-tuner.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-tuner.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-tuner.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-util.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-util.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-v4l2.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-v4l2.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-v4l2.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-v4l2.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-video-v4l.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-video-v4l.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-video-v4l.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-video-v4l.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-wm8775.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-wm8775.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2-wm8775.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2-wm8775.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/pvrusb2/pvrusb2.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/pvrusb2/pvrusb2.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h sound/aoa/codecs/snd-aoa-codec-tas.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/aoa/codecs/snd-aoa-codec-tas.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/mips/emma2rh/markeins/platform.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/emma2rh/markeins/platform.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/emma2rh/markeins/irq_markeins.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/emma2rh/markeins/irq_markeins.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/mips/emma2rh/common/irq_emma2rh.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/mips/emma2rh/common/irq_emma2rh.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/tcp_probe.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/tcp_probe.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/mtd/nand/ts7250.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/nand/ts7250.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/acpi/i2c_ec.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/i2c_ec.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/myri10ge/myri10ge_mcp_gen_header.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/myri10ge/myri10ge_mcp_gen_header.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/myri10ge/myri10ge.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/myri10ge/myri10ge.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h split-patches/kdb-v4.4-2.6.19-rc3-x86_64-1.bz2 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.19-rc3-x86_64-1.bz2.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h Documentation/ABI/testing/sysfs-power - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/ABI/testing/sysfs-power.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/amso1100/c2.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/amso1100/c2.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/amso1100/c2_alloc.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/amso1100/c2_alloc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/kdb-v4.4-2.6.19-rc3-ia64-1.bz2 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.19-rc3-ia64-1.bz2.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/kdb-v4.4-2.6.19-rc3-i386-1.bz2 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.19-rc3-i386-1.bz2.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/kdb-v4.4-2.6.19-rc3-common-1.bz2 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.19-rc3-common-1.bz2.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h security/selinux/include/selinux_netlabel.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/security/selinux/include/selinux_netlabel.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/amso1100/c2_cq.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/amso1100/c2_cq.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/amso1100/c2_provider.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/amso1100/c2_provider.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/netlabel/Kconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/netlabel/Kconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/amso1100/c2_rnic.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/amso1100/c2_rnic.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/ipv4/cipso_ipv4.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/cipso_ipv4.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/Kconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/Kconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/ehca_av.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/ehca_av.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/dccp/probe.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/probe.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/ehca_hca.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/ehca_hca.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/ehca_irq.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/ehca_irq.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/ehca_iverbs.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/ehca_iverbs.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/ehca_main.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/ehca_main.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h kernel/tsacct.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/tsacct.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h kernel/time/ntp.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/time/ntp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/ehca_mrmw.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/ehca_mrmw.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/ehca_qp.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/ehca_qp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/ehca_tools.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/ehca_tools.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ehca/hipz_hw.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ehca/hipz_hw.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ipath/ipath_iba6110.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ipath/ipath_iba6110.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/scsi/libsas.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/scsi/libsas.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/infiniband/hw/ipath/ipath_iba6120.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/infiniband/hw/ipath/ipath_iba6120.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/char/mspec.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/mspec.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/nsproxy.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/nsproxy.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/sata_via.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/sata_via.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/sata_sis.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/sata_sis.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/htirq.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/htirq.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/sata_nv.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/sata_nv.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/pata_hpt37x.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/pata_hpt37x.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/pata_artop.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/pata_artop.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/pata_amd.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/pata_amd.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/libata.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/libata.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/libata-scsi.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/libata-scsi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/libata-core.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/libata-core.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/ata_piix.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/ata_piix.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/ata/ahci.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/ata/ahci.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/dvb/frontends/dib3000mc.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/dib3000mc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/dvb/frontends/mt2060.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/mt2060.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/dvb/frontends/tda10086.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/tda10086.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/dvb/frontends/tda10086.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/tda10086.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/dvb/frontends/tda826x.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/tda826x.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/dvb/frontends/tda826x.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/tda826x.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/dvb/frontends/tua6100.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/frontends/tua6100.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/x86_64/kernel/early-quirks.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/kernel/early-quirks.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/misc/ioc4.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/misc/ioc4.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/misc/lkdtm.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/misc/lkdtm.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/mmc/tifm_sd.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mmc/tifm_sd.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sh/kernel/syscalls.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/kernel/syscalls.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sh/configs/titan_defconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/configs/titan_defconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/arm/mach-iop32x/n2100.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/mach-iop32x/n2100.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/arm/ep93xx_eth.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/arm/ep93xx_eth.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sh/configs/r7780rp_defconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/configs/r7780rp_defconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-avr32/unistd.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-avr32/unistd.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-avr32/io.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-avr32/io.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sh/boards/titan/setup.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/titan/setup.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-avr32/atomic.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-avr32/atomic.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sh/boards/se/7343/irq.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/se/7343/irq.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/sh/boards/renesas/sh7710voipgw/setup.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sh/boards/renesas/sh7710voipgw/setup.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/ehea/ehea.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/ehea/ehea.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/ehea/ehea_ethtool.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/ehea/ehea_ethtool.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/Makefile - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/boards/atstk1000/setup.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/boards/atstk1000/setup.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/boot/images/Makefile - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/boot/images/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/configs/atstk1002_defconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/configs/atstk1002_defconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/kernel/avr32_ksyms.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/kernel/avr32_ksyms.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/kernel/head.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/kernel/head.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/kernel/kprobes.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/kernel/kprobes.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/kernel/module.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/kernel/module.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/kernel/ptrace.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/kernel/ptrace.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/kernel/syscall-stubs.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/kernel/syscall-stubs.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/kernel/syscall_table.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/kernel/syscall_table.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/kernel/vmlinux.lds.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/kernel/vmlinux.lds.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/lib/Makefile - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/lib/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/lib/findbit.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/lib/findbit.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/mach-at32ap/hsmc.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/mach-at32ap/hsmc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/mach-at32ap/intc.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/mach-at32ap/intc.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/mach-at32ap/pio.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/mach-at32ap/pio.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/mach-at32ap/sm.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/mach-at32ap/sm.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/mm/init.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/mm/init.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/avr32/mm/ioremap.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/avr32/mm/ioremap.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/jbd2/transaction.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/jbd2/transaction.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/ehea/ehea_main.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/ehea/ehea_main.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/ehea/ehea_phyp.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/ehea/ehea_phyp.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/ehea/ehea_phyp.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/ehea/ehea_phyp.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/net/ehea/ehea_qmr.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/ehea/ehea_qmr.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/sysdev/qe_lib/ucc_slow.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/sysdev/qe_lib/ucc_slow.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/gfs2/ops_super.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/gfs2/ops_super.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/sysdev/qe_lib/ucc_fast.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/sysdev/qe_lib/ucc_fast.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/sysdev/qe_lib/ucc.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/sysdev/qe_lib/ucc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/sysdev/qe_lib/qe.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/sysdev/qe_lib/qe.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/gfs2/ops_address.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/gfs2/ops_address.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/platforms/83xx/mpc832x_mds.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/83xx/mpc832x_mds.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/pci/htirq.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/pci/htirq.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/gfs2/main.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/gfs2/main.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/s390/crypto/ap_bus.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/crypto/ap_bus.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/boot/zImage.lds.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/boot/zImage.lds.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/boot/wrapper - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/boot/wrapper.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_dev.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_dev.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_hwi.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_hwi.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_hwi.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_hwi.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_init.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_init.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_reg_def.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_reg_def.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_sas.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_sas.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_scb.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_scb.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_sds.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_sds.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_seq.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_seq.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/aic94xx/aic94xx_seq.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/aic94xx/aic94xx_seq.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/libsas/sas_expander.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/libsas/sas_expander.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/qla4xxx/Kconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla4xxx/Kconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/gfs2/inode.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/gfs2/inode.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ext4/resize.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ext4/resize.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/qla4xxx/ql4_dbg.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla4xxx/ql4_dbg.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/qla4xxx/ql4_glbl.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla4xxx/ql4_glbl.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/qla4xxx/ql4_mbx.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla4xxx/ql4_mbx.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/scsi/qla4xxx/ql4_os.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/qla4xxx/ql4_os.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/video/fb_ddc.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/fb_ddc.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ecryptfs/super.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ecryptfs/super.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/dlm/lockspace.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/dlm/lockspace.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ecryptfs/main.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ecryptfs/main.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ecryptfs/keystore.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ecryptfs/keystore.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ecryptfs/inode.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ecryptfs/inode.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ecryptfs/file.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ecryptfs/file.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ecryptfs/ecryptfs_kernel.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ecryptfs/ecryptfs_kernel.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ecryptfs/dentry.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ecryptfs/dentry.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/ecryptfs/crypto.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/ecryptfs/crypto.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-xfs@oss.sgi.com Thu Dec 21 03:38:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 03:38:26 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBLBcJqw030688 for ; Thu, 21 Dec 2006 03:38:21 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA03160; Thu, 21 Dec 2006 22:37:27 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBLBbP7Y69249149; Thu, 21 Dec 2006 22:37:26 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBLBbOch69290397; Thu, 21 Dec 2006 22:37:24 +1100 (AEDT) Date: Thu, 21 Dec 2006 22:37:24 +1100 From: David Chinner To: Nathan Scott Cc: David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Clear unwritten flag on during partial page truncation Message-ID: <20061221113724.GK33919298@melbourne.sgi.com> References: <20061220062813.GU44411608@melbourne.sgi.com> <1166681818.5572.190.camel@edge> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1166681818.5572.190.camel@edge> User-Agent: Mutt/1.4.2.1i X-archive-position: 10077 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1222 Lines: 33 On Thu, Dec 21, 2006 at 05:16:58PM +1100, Nathan Scott wrote: > On Wed, 2006-12-20 at 17:28 +1100, David Chinner wrote: > > Hence the solution is to clear the private buffer flags in > > xfs_vm_invalidatepage() so that when we extend the file the buffers > > on the page are all consistent. > > > > Patch below. Comments? > > Looks good Dave, nice sleuthing. > > In hindsight, it'd have been really good to have gone for the real > BH_Unwritten flag upfront, and then being able to clear that inside > discard_buffer (like was done for BH_Delay)... if we did that, then > all this new code we're adding here (to just clear_buffer_unwritten, > ultimately) and also the complete hack in xfs_count_page_state could > be removed. It still might be worth considering doing that, in case > there's other hard-to-hit-but-not-yet-uncovered bugs lurking along > the same lines. But alot of effort, with the possibility of it not > being merged at all, as it touches code outside XFS. D'oh. Yep, pretty much my thinking as well. I forgot about that hack in xfs_count_page_state() - we should be able to remove that with this change, right? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 21 08:38:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 08:38:27 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBLGcMqw012594 for ; Thu, 21 Dec 2006 08:38:23 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBLGbQJt011395; Thu, 21 Dec 2006 11:37:26 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBLGbLoe001914; Thu, 21 Dec 2006 11:37:21 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBLGbKD5006618; Thu, 21 Dec 2006 11:37:20 -0500 Message-ID: <458AB83F.4050701@sandeen.net> Date: Thu, 21 Dec 2006 10:37:19 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Barry Naujok CC: xfs-dev@corp.sgi.com, xfs@oss.sgi.com Subject: Re: [PATCH] Return failure error if something fails in xfs_growfs References: <200612210609.RAA24334@larry.melbourne.sgi.com> In-Reply-To: <200612210609.RAA24334@larry.melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10078 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 341 Lines: 12 Barry Naujok wrote: > A very simple patch that return error rather than success if something > fails in xfs_growfs. > > Barry. Try as I might to follow the grand linux tradition of finding some minor stylistic point to complain about (whitespace, formatting, choice of variable names, etc) I could not. So, looks good to me. :-) -Eric From owner-xfs@oss.sgi.com Thu Dec 21 13:52:10 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 13:52:19 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBLLq8qw013814 for ; Thu, 21 Dec 2006 13:52:09 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBLLpG38011266 for ; Thu, 21 Dec 2006 16:51:16 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBLLpBGB024736 for ; Thu, 21 Dec 2006 16:51:11 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBLLpAXV003221 for ; Thu, 21 Dec 2006 16:51:10 -0500 Message-ID: <458B01CE.1070304@sandeen.net> Date: Thu, 21 Dec 2006 15:51:10 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] remove unused "firstblock" arg from xfs_bmap_finish() Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10080 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 10683 Lines: 334 The firstblock argument to xfs_bmap_finish doesn't seem to have ever been used; I figure maybe taking it out clarifies things a tiny bit, and maybe helps the stack situation. quota/xfs_dquot.c | 2 +- xfs_attr.c | 18 +++++++----------- xfs_bmap.c | 3 +-- xfs_bmap.h | 1 - xfs_inode.c | 3 +-- xfs_iomap.c | 8 +++----- xfs_rename.c | 2 +- xfs_rtalloc.c | 2 +- xfs_vnodeops.c | 21 ++++++++++----------- 9 files changed, 25 insertions(+), 35 deletions(-) Thanks, -Eric Signed-off-by: Eric Sandeen Index: xfs-linux-allpatches/quota/xfs_dquot.c =================================================================== --- xfs-linux-allpatches.orig/quota/xfs_dquot.c +++ xfs-linux-allpatches/quota/xfs_dquot.c @@ -484,7 +484,7 @@ xfs_qm_dqalloc( xfs_trans_bhold(tp, bp); - if ((error = xfs_bmap_finish(tpp, &flist, firstblock, &committed))) { + if ((error = xfs_bmap_finish(tpp, &flist, &committed))) { goto error1; } Index: xfs-linux-allpatches/xfs_attr.c =================================================================== --- xfs-linux-allpatches.orig/xfs_attr.c +++ xfs-linux-allpatches/xfs_attr.c @@ -349,7 +349,7 @@ xfs_attr_set_int(xfs_inode_t *dp, const error = xfs_attr_shortform_to_leaf(&args); if (!error) { error = xfs_bmap_finish(&args.trans, args.flist, - *args.firstblock, &committed); + &committed); } if (error) { ASSERT(committed); @@ -976,7 +976,7 @@ xfs_attr_leaf_addname(xfs_da_args_t *arg error = xfs_attr_leaf_to_node(args); if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); + &committed); } if (error) { ASSERT(committed); @@ -1077,7 +1077,6 @@ xfs_attr_leaf_addname(xfs_da_args_t *arg if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); } if (error) { @@ -1155,7 +1154,7 @@ xfs_attr_leaf_removename(xfs_da_args_t * /* bp is gone due to xfs_da_shrink_inode */ if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); + &committed); } if (error) { ASSERT(committed); @@ -1310,7 +1309,6 @@ restart: if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); } if (error) { @@ -1350,7 +1348,7 @@ restart: error = xfs_da_split(state); if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); + &committed); } if (error) { ASSERT(committed); @@ -1462,7 +1460,6 @@ restart: if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); } if (error) { @@ -1597,7 +1594,7 @@ xfs_attr_node_removename(xfs_da_args_t * error = xfs_da_join(state); if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); + &committed); } if (error) { ASSERT(committed); @@ -1649,7 +1646,6 @@ xfs_attr_node_removename(xfs_da_args_t * if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); } if (error) { @@ -2093,7 +2089,7 @@ xfs_attr_rmtval_set(xfs_da_args_t *args) args->flist, NULL); if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); + &committed); } if (error) { ASSERT(committed); @@ -2249,7 +2245,7 @@ xfs_attr_rmtval_remove(xfs_da_args_t *ar NULL, &done); if (!error) { error = xfs_bmap_finish(&args->trans, args->flist, - *args->firstblock, &committed); + &committed); } if (error) { ASSERT(committed); Index: xfs-linux-allpatches/xfs_bmap.c =================================================================== --- xfs-linux-allpatches.orig/xfs_bmap.c +++ xfs-linux-allpatches/xfs_bmap.c @@ -4080,7 +4080,7 @@ xfs_bmap_add_attrfork( } else XFS_SB_UNLOCK(mp, s); } - if ((error = xfs_bmap_finish(&tp, &flist, firstblock, &committed))) + if ((error = xfs_bmap_finish(&tp, &flist, &committed))) goto error2; error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES, NULL); ASSERT(ip->i_df.if_ext_max == @@ -4213,7 +4213,6 @@ int /* error */ xfs_bmap_finish( xfs_trans_t **tp, /* transaction pointer addr */ xfs_bmap_free_t *flist, /* i/o: list extents to free */ - xfs_fsblock_t firstblock, /* controlled ag for allocs */ int *committed) /* xact committed or not */ { xfs_efd_log_item_t *efd; /* extent free data */ Index: xfs-linux-allpatches/xfs_bmap.h =================================================================== --- xfs-linux-allpatches.orig/xfs_bmap.h +++ xfs-linux-allpatches/xfs_bmap.h @@ -202,7 +202,6 @@ int /* error */ xfs_bmap_finish( struct xfs_trans **tp, /* transaction pointer addr */ xfs_bmap_free_t *flist, /* i/o: list extents to free */ - xfs_fsblock_t firstblock, /* controlled a.g. for allocs */ int *committed); /* xact committed or not */ /* Index: xfs-linux-allpatches/xfs_inode.c =================================================================== --- xfs-linux-allpatches.orig/xfs_inode.c +++ xfs-linux-allpatches/xfs_inode.c @@ -1699,8 +1699,7 @@ xfs_itruncate_finish( * Duplicate the transaction that has the permanent * reservation and commit the old transaction. */ - error = xfs_bmap_finish(tp, &free_list, first_block, - &committed); + error = xfs_bmap_finish(tp, &free_list, &committed); ntp = *tp; if (error) { /* Index: xfs-linux-allpatches/xfs_iomap.c =================================================================== --- xfs-linux-allpatches.orig/xfs_iomap.c +++ xfs-linux-allpatches/xfs_iomap.c @@ -542,7 +542,7 @@ xfs_iomap_write_direct( /* * Complete the transaction */ - error = xfs_bmap_finish(&tp, &free_list, firstfsb, &committed); + error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) goto error0; error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); @@ -838,8 +838,7 @@ xfs_iomap_write_allocate( if (error) goto trans_cancel; - error = xfs_bmap_finish(&tp, &free_list, - first_block, &committed); + error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) goto trans_cancel; @@ -947,8 +946,7 @@ xfs_iomap_write_unwritten( if (error) goto error_on_bmapi_transaction; - error = xfs_bmap_finish(&(tp), &(free_list), - firstfsb, &committed); + error = xfs_bmap_finish(&(tp), &(free_list), &committed); if (error) goto error_on_bmapi_transaction; Index: xfs-linux-allpatches/xfs_rename.c =================================================================== --- xfs-linux-allpatches.orig/xfs_rename.c +++ xfs-linux-allpatches/xfs_rename.c @@ -565,7 +565,7 @@ xfs_rename( IHOLD(target_ip); IHOLD(src_ip); - error = xfs_bmap_finish(&tp, &free_list, first_block, &committed); + error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) { xfs_bmap_cancel(&free_list); xfs_trans_cancel(tp, (XFS_TRANS_RELEASE_LOG_RES | Index: xfs-linux-allpatches/xfs_rtalloc.c =================================================================== --- xfs-linux-allpatches.orig/xfs_rtalloc.c +++ xfs-linux-allpatches/xfs_rtalloc.c @@ -147,7 +147,7 @@ xfs_growfs_rt_alloc( /* * Free any blocks freed up in the transaction, then commit. */ - error = xfs_bmap_finish(&tp, &flist, firstblock, &committed); + error = xfs_bmap_finish(&tp, &flist, &committed); if (error) goto error_exit; xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); Index: xfs-linux-allpatches/xfs_vnodeops.c =================================================================== --- xfs-linux-allpatches.orig/xfs_vnodeops.c +++ xfs-linux-allpatches/xfs_vnodeops.c @@ -1381,7 +1381,7 @@ xfs_inactive_symlink_rmt( /* * Commit the first transaction. This logs the EFI and the inode. */ - if ((error = xfs_bmap_finish(&tp, &free_list, first_block, &committed))) + if ((error = xfs_bmap_finish(&tp, &free_list, &committed))) goto error1; /* * The transaction must have been committed, since there were @@ -1790,8 +1790,7 @@ xfs_inactive( * Just ignore errors at this point. There is * nothing we can do except to try to keep going. */ - (void) xfs_bmap_finish(&tp, &free_list, first_block, - &committed); + (void) xfs_bmap_finish(&tp, &free_list, &committed); (void) xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES, NULL); } /* @@ -2022,7 +2021,7 @@ xfs_create( IHOLD(ip); vp = XFS_ITOV(ip); - error = xfs_bmap_finish(&tp, &free_list, first_block, &committed); + error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) { xfs_bmap_cancel(&free_list); goto abort_rele; @@ -2507,7 +2506,7 @@ xfs_remove( xfs_trans_set_sync(tp); } - error = xfs_bmap_finish(&tp, &free_list, first_block, &committed); + error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) { REMOVE_DEBUG_TRACE(__LINE__); goto error_rele; @@ -2715,7 +2714,7 @@ xfs_link( xfs_trans_set_sync(tp); } - error = xfs_bmap_finish (&tp, &free_list, first_block, &committed); + error = xfs_bmap_finish (&tp, &free_list, &committed); if (error) { xfs_bmap_cancel(&free_list); goto abort_return; @@ -2932,7 +2931,7 @@ xfs_mkdir( xfs_trans_set_sync(tp); } - error = xfs_bmap_finish(&tp, &free_list, first_block, &committed); + error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) { IRELE(cdp); goto error2; @@ -3183,7 +3182,7 @@ xfs_rmdir( xfs_trans_set_sync(tp); } - error = xfs_bmap_finish (&tp, &free_list, first_block, &committed); + error = xfs_bmap_finish (&tp, &free_list, &committed); if (error) { xfs_bmap_cancel(&free_list); xfs_trans_cancel(tp, (XFS_TRANS_RELEASE_LOG_RES | @@ -3533,7 +3532,7 @@ xfs_symlink( */ IHOLD(ip); - error = xfs_bmap_finish(&tp, &free_list, first_block, &committed); + error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) { goto error2; } @@ -4145,7 +4144,7 @@ retry: /* * Complete the transaction */ - error = xfs_bmap_finish(&tp, &free_list, firstfsb, &committed); + error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) { goto error0; } @@ -4452,7 +4451,7 @@ xfs_free_file_space( /* * complete the transaction */ - error = xfs_bmap_finish(&tp, &free_list, firstfsb, &committed); + error = xfs_bmap_finish(&tp, &free_list, &committed); if (error) { goto error0; } From owner-xfs@oss.sgi.com Thu Dec 21 14:00:26 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 14:00:29 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBLM0Oqw015129 for ; Thu, 21 Dec 2006 14:00:25 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id kBLLxXRe016594 for ; Thu, 21 Dec 2006 16:59:33 -0500 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBLLxXJ2026872 for ; Thu, 21 Dec 2006 16:59:33 -0500 Received: from [10.15.80.10] (neon.msp.redhat.com [10.15.80.10]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id kBLLxXkY003978 for ; Thu, 21 Dec 2006 16:59:33 -0500 Message-ID: <458B03C4.6000306@sandeen.net> Date: Thu, 21 Dec 2006 15:59:32 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: [PATCH] remove unused arguments from the XFS_BTREE_*_ADDR functions Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10081 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 17811 Lines: 439 Unused arguments to macros... I don't honestly remember how I stumbled across these... It makes it incrementally clearer to read the code when the top of a macro spaghetti-pile only receives the 3 arguments it uses, rather than 2 extra ones which are not used. Also when you start pulling this thread out of the sweater (i.e. remove unused args from XFS_BTREE_*_ADDR), a couple other third arms etc fall off too. If they're not used in the macro, then they sometimes don't need to be passed to the function calling the macro either, etc.... I suppose this one may take some extra scrutiny to review, but it's a bunch of dead & therefore confusing code, near as I can tell. Thanks, -Eric xfs_alloc_btree.h | 10 +++------- xfs_bmap.c | 35 ++++++++++++----------------------- xfs_bmap_btree.c | 8 ++++---- xfs_bmap_btree.h | 46 +++++++++++----------------------------------- xfs_btree.h | 6 +++--- xfs_fsops.c | 6 ++---- xfs_ialloc_btree.h | 10 ++++------ xfsidbg.c | 19 +++++++++---------- 8 files changed, 48 insertions(+), 92 deletions(-) Signed-off-by: Eric Sandeen Index: xfs-linux-allpatches/xfs_alloc_btree.h =================================================================== --- xfs-linux-allpatches.orig/xfs_alloc_btree.h +++ xfs-linux-allpatches/xfs_alloc_btree.h @@ -58,7 +58,6 @@ typedef struct xfs_btree_sblock xfs_allo /* * Real block structures have a size equal to the disk block size. */ -#define XFS_ALLOC_BLOCK_SIZE(lev,cur) (1 << (cur)->bc_blocklog) #define XFS_ALLOC_BLOCK_MAXRECS(lev,cur) ((cur)->bc_mp->m_alloc_mxr[lev != 0]) #define XFS_ALLOC_BLOCK_MINRECS(lev,cur) ((cur)->bc_mp->m_alloc_mnr[lev != 0]) @@ -87,16 +86,13 @@ typedef struct xfs_btree_sblock xfs_allo * Record, key, and pointer address macros for btree blocks. */ #define XFS_ALLOC_REC_ADDR(bb,i,cur) \ - XFS_BTREE_REC_ADDR(XFS_ALLOC_BLOCK_SIZE(0,cur), xfs_alloc, \ - bb, i, XFS_ALLOC_BLOCK_MAXRECS(0, cur)) + XFS_BTREE_REC_ADDR(xfs_alloc, bb, i) #define XFS_ALLOC_KEY_ADDR(bb,i,cur) \ - XFS_BTREE_KEY_ADDR(XFS_ALLOC_BLOCK_SIZE(1,cur), xfs_alloc, \ - bb, i, XFS_ALLOC_BLOCK_MAXRECS(1, cur)) + XFS_BTREE_KEY_ADDR(xfs_alloc, bb, i) #define XFS_ALLOC_PTR_ADDR(bb,i,cur) \ - XFS_BTREE_PTR_ADDR(XFS_ALLOC_BLOCK_SIZE(1,cur), xfs_alloc, \ - bb, i, XFS_ALLOC_BLOCK_MAXRECS(1, cur)) + XFS_BTREE_PTR_ADDR(xfs_alloc, bb, i, XFS_ALLOC_BLOCK_MAXRECS(1, cur)) /* * Decrement cursor by one record at the level. Index: xfs-linux-allpatches/xfs_bmap.c =================================================================== --- xfs-linux-allpatches.orig/xfs_bmap.c +++ xfs-linux-allpatches/xfs_bmap.c @@ -410,7 +410,6 @@ xfs_bmap_count_leaves( STATIC int xfs_bmap_disk_count_leaves( xfs_ifork_t *ifp, - xfs_mount_t *mp, xfs_extnum_t idx, xfs_bmbt_block_t *block, int numrecs, @@ -4533,8 +4532,7 @@ xfs_bmap_read_extents( error0); if (level == 0) break; - pp = XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, block, - 1, mp->m_bmap_dmxr[1]); + pp = XFS_BTREE_PTR_ADDR(xfs_bmbt, block, 1, mp->m_bmap_dmxr[1]); bno = be64_to_cpu(*pp); XFS_WANT_CORRUPTED_GOTO(XFS_FSB_SANITY_CHECK(mp, bno), error0); xfs_trans_brelse(tp, bp); @@ -4577,8 +4575,7 @@ xfs_bmap_read_extents( /* * Copy records into the extent records. */ - frp = XFS_BTREE_REC_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, - block, 1, mp->m_bmap_dmxr[0]); + frp = XFS_BTREE_REC_ADDR(xfs_bmbt, block, 1); start = i; for (j = 0; j < num_recs; j++, i++, frp++) { trp = xfs_iext_get_ext(ifp, i); @@ -6156,8 +6153,7 @@ xfs_check_block( if (root) { keyp = XFS_BMAP_BROOT_KEY_ADDR(block, i, sz); } else { - keyp = XFS_BTREE_KEY_ADDR(mp->m_sb.sb_blocksize, - xfs_bmbt, block, i, dmxr); + keyp = XFS_BTREE_KEY_ADDR(xfs_bmbt, block, i); } if (prevp) { @@ -6172,15 +6168,14 @@ xfs_check_block( if (root) { pp = XFS_BMAP_BROOT_PTR_ADDR(block, i, sz); } else { - pp = XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, - xfs_bmbt, block, i, dmxr); + pp = XFS_BTREE_PTR_ADDR(xfs_bmbt, block, i, dmxr); } for (j = i+1; j <= be16_to_cpu(block->bb_numrecs); j++) { if (root) { thispa = XFS_BMAP_BROOT_PTR_ADDR(block, j, sz); } else { - thispa = XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, - xfs_bmbt, block, j, dmxr); + thispa = XFS_BTREE_PTR_ADDR(xfs_bmbt, block, j, + dmxr); } if (*thispa == *pp) { cmn_err(CE_WARN, "%s: thispa(%d) == pp(%d) %Ld", @@ -6267,8 +6262,7 @@ xfs_bmap_check_leaf_extents( */ xfs_check_block(block, mp, 0, 0); - pp = XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, block, - 1, mp->m_bmap_dmxr[1]); + pp = XFS_BTREE_PTR_ADDR(xfs_bmbt, block, 1, mp->m_bmap_dmxr[1]); bno = be64_to_cpu(*pp); XFS_WANT_CORRUPTED_GOTO(XFS_FSB_SANITY_CHECK(mp, bno), error0); if (bp_release) { @@ -6305,11 +6299,9 @@ xfs_bmap_check_leaf_extents( * conform with the first entry in this one. */ - ep = XFS_BTREE_REC_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, - block, 1, mp->m_bmap_dmxr[0]); + ep = XFS_BTREE_REC_ADDR(xfs_bmbt, block, 1); for (j = 1; j < num_recs; j++) { - nextp = XFS_BTREE_REC_ADDR(mp->m_sb.sb_blocksize, xfs_bmbt, - block, j + 1, mp->m_bmap_dmxr[0]); + nextp = XFS_BTREE_REC_ADDR(xfs_bmbt, block, j + 1); if (lastp) { xfs_btree_check_rec(XFS_BTNUM_BMAP, (void *)lastp, (void *)ep); @@ -6454,8 +6446,7 @@ xfs_bmap_count_tree( } /* Dive to the next level */ - pp = XFS_BTREE_PTR_ADDR(mp->m_sb.sb_blocksize, - xfs_bmbt, block, 1, mp->m_bmap_dmxr[1]); + pp = XFS_BTREE_PTR_ADDR(xfs_bmbt, block, 1, mp->m_bmap_dmxr[1]); bno = be64_to_cpu(*pp); if (unlikely((error = xfs_bmap_count_tree(mp, tp, ifp, bno, level, count)) < 0)) { @@ -6470,7 +6461,7 @@ xfs_bmap_count_tree( for (;;) { nextbno = be64_to_cpu(block->bb_rightsib); numrecs = be16_to_cpu(block->bb_numrecs); - if (unlikely(xfs_bmap_disk_count_leaves(ifp, mp, + if (unlikely(xfs_bmap_disk_count_leaves(ifp, 0, block, numrecs, count) < 0)) { xfs_trans_brelse(tp, bp); XFS_ERROR_REPORT("xfs_bmap_count_tree(2)", @@ -6518,7 +6509,6 @@ xfs_bmap_count_leaves( int xfs_bmap_disk_count_leaves( xfs_ifork_t *ifp, - xfs_mount_t *mp, xfs_extnum_t idx, xfs_bmbt_block_t *block, int numrecs, @@ -6528,8 +6518,7 @@ xfs_bmap_disk_count_leaves( xfs_bmbt_rec_t *frp; for (b = 1; b <= numrecs; b++) { - frp = XFS_BTREE_REC_ADDR(mp->m_sb.sb_blocksize, - xfs_bmbt, block, idx + b, mp->m_bmap_dmxr[0]); + frp = XFS_BTREE_REC_ADDR(xfs_bmbt, block, idx + b); *count += xfs_bmbt_disk_get_blockcount(frp); } return 0; Index: xfs-linux-allpatches/xfs_bmap_btree.c =================================================================== --- xfs-linux-allpatches.orig/xfs_bmap_btree.c +++ xfs-linux-allpatches/xfs_bmap_btree.c @@ -1731,9 +1731,9 @@ xfs_bmdr_to_bmbt( rblock->bb_leftsib = cpu_to_be64(NULLDFSBNO); rblock->bb_rightsib = cpu_to_be64(NULLDFSBNO); dmxr = (int)XFS_BTREE_BLOCK_MAXRECS(dblocklen, xfs_bmdr, 0); - fkp = XFS_BTREE_KEY_ADDR(dblocklen, xfs_bmdr, dblock, 1, dmxr); + fkp = XFS_BTREE_KEY_ADDR(xfs_bmdr, dblock, 1); tkp = XFS_BMAP_BROOT_KEY_ADDR(rblock, 1, rblocklen); - fpp = XFS_BTREE_PTR_ADDR(dblocklen, xfs_bmdr, dblock, 1, dmxr); + fpp = XFS_BTREE_PTR_ADDR(xfs_bmdr, dblock, 1, dmxr); tpp = XFS_BMAP_BROOT_PTR_ADDR(rblock, 1, rblocklen); dmxr = be16_to_cpu(dblock->bb_numrecs); memcpy(tkp, fkp, sizeof(*fkp) * dmxr); @@ -2684,9 +2684,9 @@ xfs_bmbt_to_bmdr( dblock->bb_numrecs = rblock->bb_numrecs; dmxr = (int)XFS_BTREE_BLOCK_MAXRECS(dblocklen, xfs_bmdr, 0); fkp = XFS_BMAP_BROOT_KEY_ADDR(rblock, 1, rblocklen); - tkp = XFS_BTREE_KEY_ADDR(dblocklen, xfs_bmdr, dblock, 1, dmxr); + tkp = XFS_BTREE_KEY_ADDR(xfs_bmdr, dblock, 1); fpp = XFS_BMAP_BROOT_PTR_ADDR(rblock, 1, rblocklen); - tpp = XFS_BTREE_PTR_ADDR(dblocklen, xfs_bmdr, dblock, 1, dmxr); + tpp = XFS_BTREE_PTR_ADDR(xfs_bmdr, dblock, 1, dmxr); dmxr = be16_to_cpu(dblock->bb_numrecs); memcpy(tkp, fkp, sizeof(*fkp) * dmxr); memcpy(tpp, fpp, sizeof(*fpp) * dmxr); Index: xfs-linux-allpatches/xfs_bmap_btree.h =================================================================== --- xfs-linux-allpatches.orig/xfs_bmap_btree.h +++ xfs-linux-allpatches/xfs_bmap_btree.h @@ -175,19 +175,11 @@ typedef struct xfs_btree_lblock xfs_bmbt #define XFS_BUF_TO_BMBT_BLOCK(bp) ((xfs_bmbt_block_t *)XFS_BUF_PTR(bp)) -#define XFS_BMAP_IBLOCK_SIZE(lev,cur) (1 << (cur)->bc_blocklog) #define XFS_BMAP_RBLOCK_DSIZE(lev,cur) ((cur)->bc_private.b.forksize) #define XFS_BMAP_RBLOCK_ISIZE(lev,cur) \ ((int)XFS_IFORK_PTR((cur)->bc_private.b.ip, \ (cur)->bc_private.b.whichfork)->if_broot_bytes) -#define XFS_BMAP_BLOCK_DSIZE(lev,cur) \ - (((lev) == (cur)->bc_nlevels - 1 ? \ - XFS_BMAP_RBLOCK_DSIZE(lev,cur) : XFS_BMAP_IBLOCK_SIZE(lev,cur))) -#define XFS_BMAP_BLOCK_ISIZE(lev,cur) \ - (((lev) == (cur)->bc_nlevels - 1 ? \ - XFS_BMAP_RBLOCK_ISIZE(lev,cur) : XFS_BMAP_IBLOCK_SIZE(lev,cur))) - #define XFS_BMAP_BLOCK_DMAXRECS(lev,cur) \ (((lev) == (cur)->bc_nlevels - 1 ? \ XFS_BTREE_BLOCK_MAXRECS(XFS_BMAP_RBLOCK_DSIZE(lev,cur), \ @@ -210,37 +202,21 @@ typedef struct xfs_btree_lblock xfs_bmbt xfs_bmbt, (lev) == 0) : \ ((cur)->bc_mp->m_bmap_dmnr[(lev) != 0]))) -#define XFS_BMAP_REC_DADDR(bb,i,cur) \ - (XFS_BTREE_REC_ADDR(XFS_BMAP_BLOCK_DSIZE( \ - be16_to_cpu((bb)->bb_level), cur), \ - xfs_bmbt, bb, i, XFS_BMAP_BLOCK_DMAXRECS( \ - be16_to_cpu((bb)->bb_level), cur))) -#define XFS_BMAP_REC_IADDR(bb,i,cur) \ - (XFS_BTREE_REC_ADDR(XFS_BMAP_BLOCK_ISIZE( \ - be16_to_cpu((bb)->bb_level), cur), \ - xfs_bmbt, bb, i, XFS_BMAP_BLOCK_IMAXRECS( \ - be16_to_cpu((bb)->bb_level), cur))) +#define XFS_BMAP_REC_DADDR(bb,i,cur) (XFS_BTREE_REC_ADDR(xfs_bmbt, bb, i)) + +#define XFS_BMAP_REC_IADDR(bb,i,cur) (XFS_BTREE_REC_ADDR(xfs_bmbt, bb, i)) #define XFS_BMAP_KEY_DADDR(bb,i,cur) \ - (XFS_BTREE_KEY_ADDR(XFS_BMAP_BLOCK_DSIZE( \ - be16_to_cpu((bb)->bb_level), cur), \ - xfs_bmbt, bb, i, XFS_BMAP_BLOCK_DMAXRECS( \ - be16_to_cpu((bb)->bb_level), cur))) + (XFS_BTREE_KEY_ADDR(xfs_bmbt, bb, i)) + #define XFS_BMAP_KEY_IADDR(bb,i,cur) \ - (XFS_BTREE_KEY_ADDR(XFS_BMAP_BLOCK_ISIZE( \ - be16_to_cpu((bb)->bb_level), cur), \ - xfs_bmbt, bb, i, XFS_BMAP_BLOCK_IMAXRECS( \ - be16_to_cpu((bb)->bb_level), cur))) + (XFS_BTREE_KEY_ADDR(xfs_bmbt, bb, i)) #define XFS_BMAP_PTR_DADDR(bb,i,cur) \ - (XFS_BTREE_PTR_ADDR(XFS_BMAP_BLOCK_DSIZE( \ - be16_to_cpu((bb)->bb_level), cur), \ - xfs_bmbt, bb, i, XFS_BMAP_BLOCK_DMAXRECS( \ + (XFS_BTREE_PTR_ADDR(xfs_bmbt, bb, i, XFS_BMAP_BLOCK_DMAXRECS( \ be16_to_cpu((bb)->bb_level), cur))) #define XFS_BMAP_PTR_IADDR(bb,i,cur) \ - (XFS_BTREE_PTR_ADDR(XFS_BMAP_BLOCK_ISIZE( \ - be16_to_cpu((bb)->bb_level), cur), \ - xfs_bmbt, bb, i, XFS_BMAP_BLOCK_IMAXRECS( \ + (XFS_BTREE_PTR_ADDR(xfs_bmbt, bb, i, XFS_BMAP_BLOCK_IMAXRECS( \ be16_to_cpu((bb)->bb_level), cur))) /* @@ -248,11 +224,11 @@ typedef struct xfs_btree_lblock xfs_bmbt * we don't have a cursor. */ #define XFS_BMAP_BROOT_REC_ADDR(bb,i,sz) \ - (XFS_BTREE_REC_ADDR(sz,xfs_bmbt,bb,i,XFS_BMAP_BROOT_MAXRECS(sz))) + (XFS_BTREE_REC_ADDR(xfs_bmbt,bb,i)) #define XFS_BMAP_BROOT_KEY_ADDR(bb,i,sz) \ - (XFS_BTREE_KEY_ADDR(sz,xfs_bmbt,bb,i,XFS_BMAP_BROOT_MAXRECS(sz))) + (XFS_BTREE_KEY_ADDR(xfs_bmbt,bb,i)) #define XFS_BMAP_BROOT_PTR_ADDR(bb,i,sz) \ - (XFS_BTREE_PTR_ADDR(sz,xfs_bmbt,bb,i,XFS_BMAP_BROOT_MAXRECS(sz))) + (XFS_BTREE_PTR_ADDR(xfs_bmbt,bb,i,XFS_BMAP_BROOT_MAXRECS(sz))) #define XFS_BMAP_BROOT_NUMRECS(bb) be16_to_cpu((bb)->bb_numrecs) #define XFS_BMAP_BROOT_MAXRECS(sz) XFS_BTREE_BLOCK_MAXRECS(sz,xfs_bmbt,0) Index: xfs-linux-allpatches/xfs_btree.h =================================================================== --- xfs-linux-allpatches.orig/xfs_btree.h +++ xfs-linux-allpatches/xfs_btree.h @@ -122,13 +122,13 @@ extern const __uint32_t xfs_magics[]; * Given block size, type prefix, block pointer, and index of requested entry * (first entry numbered 1). */ -#define XFS_BTREE_REC_ADDR(bsz,t,bb,i,mxr) \ +#define XFS_BTREE_REC_ADDR(t,bb,i) \ ((t ## _rec_t *)((char *)(bb) + sizeof(t ## _block_t) + \ ((i) - 1) * sizeof(t ## _rec_t))) -#define XFS_BTREE_KEY_ADDR(bsz,t,bb,i,mxr) \ +#define XFS_BTREE_KEY_ADDR(t,bb,i) \ ((t ## _key_t *)((char *)(bb) + sizeof(t ## _block_t) + \ ((i) - 1) * sizeof(t ## _key_t))) -#define XFS_BTREE_PTR_ADDR(bsz,t,bb,i,mxr) \ +#define XFS_BTREE_PTR_ADDR(t,bb,i,mxr) \ ((t ## _ptr_t *)((char *)(bb) + sizeof(t ## _block_t) + \ (mxr) * sizeof(t ## _key_t) + ((i) - 1) * sizeof(t ## _ptr_t))) Index: xfs-linux-allpatches/xfs_fsops.c =================================================================== --- xfs-linux-allpatches.orig/xfs_fsops.c +++ xfs-linux-allpatches/xfs_fsops.c @@ -250,8 +250,7 @@ xfs_growfs_data_private( block->bb_numrecs = cpu_to_be16(1); block->bb_leftsib = cpu_to_be32(NULLAGBLOCK); block->bb_rightsib = cpu_to_be32(NULLAGBLOCK); - arec = XFS_BTREE_REC_ADDR(mp->m_sb.sb_blocksize, xfs_alloc, - block, 1, mp->m_alloc_mxr[0]); + arec = XFS_BTREE_REC_ADDR(xfs_alloc, block, 1); arec->ar_startblock = cpu_to_be32(XFS_PREALLOC_BLOCKS(mp)); arec->ar_blockcount = cpu_to_be32( agsize - be32_to_cpu(arec->ar_startblock)); @@ -272,8 +271,7 @@ xfs_growfs_data_private( block->bb_numrecs = cpu_to_be16(1); block->bb_leftsib = cpu_to_be32(NULLAGBLOCK); block->bb_rightsib = cpu_to_be32(NULLAGBLOCK); - arec = XFS_BTREE_REC_ADDR(mp->m_sb.sb_blocksize, xfs_alloc, - block, 1, mp->m_alloc_mxr[0]); + arec = XFS_BTREE_REC_ADDR(xfs_alloc, block, 1); arec->ar_startblock = cpu_to_be32(XFS_PREALLOC_BLOCKS(mp)); arec->ar_blockcount = cpu_to_be32( agsize - be32_to_cpu(arec->ar_startblock)); Index: xfs-linux-allpatches/xfs_ialloc_btree.h =================================================================== --- xfs-linux-allpatches.orig/xfs_ialloc_btree.h +++ xfs-linux-allpatches/xfs_ialloc_btree.h @@ -89,7 +89,6 @@ typedef struct xfs_btree_sblock xfs_inob /* * Real block structures have a size equal to the disk block size. */ -#define XFS_INOBT_BLOCK_SIZE(lev,cur) (1 << (cur)->bc_blocklog) #define XFS_INOBT_BLOCK_MAXRECS(lev,cur) ((cur)->bc_mp->m_inobt_mxr[lev != 0]) #define XFS_INOBT_BLOCK_MINRECS(lev,cur) ((cur)->bc_mp->m_inobt_mnr[lev != 0]) #define XFS_INOBT_IS_LAST_REC(cur) \ @@ -110,14 +109,13 @@ typedef struct xfs_btree_sblock xfs_inob * Record, key, and pointer address macros for btree blocks. */ #define XFS_INOBT_REC_ADDR(bb,i,cur) \ - (XFS_BTREE_REC_ADDR(XFS_INOBT_BLOCK_SIZE(0,cur), xfs_inobt, bb, \ - i, XFS_INOBT_BLOCK_MAXRECS(0, cur))) + (XFS_BTREE_REC_ADDR(xfs_inobt, bb, i)) + #define XFS_INOBT_KEY_ADDR(bb,i,cur) \ - (XFS_BTREE_KEY_ADDR(XFS_INOBT_BLOCK_SIZE(1,cur), xfs_inobt, bb, \ - i, XFS_INOBT_BLOCK_MAXRECS(1, cur))) + (XFS_BTREE_KEY_ADDR(xfs_inobt, bb, i)) #define XFS_INOBT_PTR_ADDR(bb,i,cur) \ - (XFS_BTREE_PTR_ADDR(XFS_INOBT_BLOCK_SIZE(1,cur), xfs_inobt, bb, \ + (XFS_BTREE_PTR_ADDR(xfs_inobt, bb, \ i, XFS_INOBT_BLOCK_MAXRECS(1, cur))) /* Index: xfs-linux-allpatches/xfsidbg.c =================================================================== --- xfs-linux-allpatches.orig/xfsidbg.c +++ xfs-linux-allpatches/xfsidbg.c @@ -3227,7 +3227,7 @@ xfs_btalloc(xfs_alloc_block_t *bt, int b for (i = 1; i <= be16_to_cpu(bt->bb_numrecs); i++) { xfs_alloc_rec_t *r; - r = XFS_BTREE_REC_ADDR(bsz, xfs_alloc, bt, i, 0); + r = XFS_BTREE_REC_ADDR(xfs_alloc, bt, i); kdb_printf("rec %d startblock 0x%x blockcount %d\n", i, be32_to_cpu(r->ar_startblock), @@ -3241,8 +3241,8 @@ xfs_btalloc(xfs_alloc_block_t *bt, int b xfs_alloc_key_t *k; xfs_alloc_ptr_t *p; - k = XFS_BTREE_KEY_ADDR(bsz, xfs_alloc, bt, i, mxr); - p = XFS_BTREE_PTR_ADDR(bsz, xfs_alloc, bt, i, mxr); + k = XFS_BTREE_KEY_ADDR(xfs_alloc, bt, i); + p = XFS_BTREE_PTR_ADDR(xfs_alloc, bt, i, mxr); kdb_printf("key %d startblock 0x%x blockcount %d ptr 0x%x\n", i, be32_to_cpu(k->ar_startblock), @@ -3271,8 +3271,7 @@ xfs_btbmap(xfs_bmbt_block_t *bt, int bsz xfs_bmbt_rec_t *r; xfs_bmbt_irec_t irec; - r = (xfs_bmbt_rec_t *)XFS_BTREE_REC_ADDR(bsz, - xfs_bmbt, bt, i, 0); + r = (xfs_bmbt_rec_t *)XFS_BTREE_REC_ADDR(xfs_bmbt, bt, i); xfs_bmbt_disk_get_all((xfs_bmbt_rec_t *)r, &irec); kdb_printf("rec %d startoff %Ld startblock %Lx blockcount %Ld flag %d\n", @@ -3288,8 +3287,8 @@ xfs_btbmap(xfs_bmbt_block_t *bt, int bsz xfs_bmbt_key_t *k; xfs_bmbt_ptr_t *p; - k = XFS_BTREE_KEY_ADDR(bsz, xfs_bmbt, bt, i, mxr); - p = XFS_BTREE_PTR_ADDR(bsz, xfs_bmbt, bt, i, mxr); + k = XFS_BTREE_KEY_ADDR(xfs_bmbt, bt, i); + p = XFS_BTREE_PTR_ADDR(xfs_bmbt, bt, i, mxr); kdb_printf("key %d startoff %Ld ", i, (unsigned long long)INT_GET(k->br_startoff, ARCH_CONVERT)); kdb_printf("ptr %Lx\n", @@ -3316,7 +3315,7 @@ xfs_btino(xfs_inobt_block_t *bt, int bsz for (i = 1; i <= be16_to_cpu(bt->bb_numrecs); i++) { xfs_inobt_rec_t *r; - r = XFS_BTREE_REC_ADDR(bsz, xfs_inobt, bt, i, 0); + r = XFS_BTREE_REC_ADDR(xfs_inobt, bt, i); kdb_printf("rec %d startino 0x%x freecount %d, free %Lx\n", i, INT_GET(r->ir_startino, ARCH_CONVERT), INT_GET(r->ir_freecount, ARCH_CONVERT), @@ -3330,8 +3329,8 @@ xfs_btino(xfs_inobt_block_t *bt, int bsz xfs_inobt_key_t *k; xfs_inobt_ptr_t *p; - k = XFS_BTREE_KEY_ADDR(bsz, xfs_inobt, bt, i, mxr); - p = XFS_BTREE_PTR_ADDR(bsz, xfs_inobt, bt, i, mxr); + k = XFS_BTREE_KEY_ADDR(xfs_inobt, bt, i); + p = XFS_BTREE_PTR_ADDR(xfs_inobt, bt, i, mxr); kdb_printf("key %d startino 0x%x ptr 0x%x\n", i, INT_GET(k->ir_startino, ARCH_CONVERT), be32_to_cpu(*p)); From owner-xfs@oss.sgi.com Thu Dec 21 14:36:49 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 14:36:52 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBLMajqw019072 for ; Thu, 21 Dec 2006 14:36:47 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA17257; Fri, 10 Nov 2006 13:03:05 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 5809258FA286; Fri, 10 Nov 2006 13:03:05 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 957005 - fs/xfs/xfs_dmapi.h Removal of old code Message-Id: <20061110020305.5809258FA286@chook.melbourne.sgi.com> Date: Fri, 10 Nov 2006 13:03:05 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10082 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 869 Lines: 24 Remove KERNEL_VERSION macros from xfs_dmapi.h Date: Fri Nov 10 13:01:22 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes,michal.k.k.piotrowski@gmail.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27398a fs/xfs/linux-2.4/xfs_dmapi_priv.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_dmapi_priv.h - Move 2.4 specific dmapi macros here. fs/xfs/linux-2.6/xfs_dmapi_priv.h - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_dmapi_priv.h - Move 2.6 specific dmapi macros here. fs/xfs/xfs_dmapi.h - 1.58 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dmapi.h.diff?r1=text&tr1=1.58&r2=text&tr2=1.57&f=h - Split platform specific macros out into platform specifc headers. From owner-xfs@oss.sgi.com Thu Dec 21 15:19:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 15:20:01 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBLNJsqw023740 for ; Thu, 21 Dec 2006 15:19:55 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA22462; Fri, 22 Dec 2006 10:05:31 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBLN5U7Y70038604; Fri, 22 Dec 2006 10:05:31 +1100 (AEDT) Received: (from bnaujok@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBLN5T7f70006633; Fri, 22 Dec 2006 10:05:29 +1100 (AEDT) Date: Fri, 22 Dec 2006 10:05:29 +1100 (AEDT) From: Barry Naujok Message-Id: <200612212305.kBLN5T7f70006633@snort.melbourne.sgi.com> To: sgi.bugs.xfs@engr.sgi.com Cc: linux-xfs@oss.sgi.com Subject: TAKE 959492 - xfs_growfs should return an error on failure X-archive-position: 10083 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@snort.melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 560 Lines: 17 Return error (1) if something fails in xfs_growfs Date: Fri Dec 22 10:05:06 AEDT 2006 Workarea: snort.melbourne.sgi.com:/home/bnaujok/isms/repair Inspected by: nathans@debian.org,sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:27802a xfsprogs/growfs/xfs_growfs.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/xfs_growfs.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h - Return error (1) if something fails in xfs_growfs From owner-xfs@oss.sgi.com Thu Dec 21 15:26:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 15:27:01 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBLNQrqw025064 for ; Thu, 21 Dec 2006 15:26:55 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23228; Fri, 22 Dec 2006 10:25:58 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 92B5058CA546; Fri, 22 Dec 2006 10:25:58 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 950149 - XFSQA: Assert fail !(iomapp->iomap_flags & IOMAP_DELAY) in test 083 Message-Id: <20061221232558.92B5058CA546@chook.melbourne.sgi.com> Date: Fri, 22 Dec 2006 10:25:58 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10084 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1175 Lines: 28 Clear unwritten buffer flag on partial page invalidation If we have a page with unwritten extents on it, and we do a partial page truncation, we fail to clear the private unwritten buffer flag on buffers that are now past EOF. If we then extend the file into those blocks via a write, we will make the wrong allocation decision when writing the new data to disk because of the incorrect unwritten flag on the buffer. Hence we need to clear the unwritten flag in xfs_vm_invalidatepage to ensure that the state of the buffers on the page beyond EOF are in the correct state in case they are reused. Date: Fri Dec 22 10:25:11 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: lachlan,nathans@aconex.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27804a fs/xfs/linux-2.6/xfs_aops.c - 1.137 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.137&r2=text&tr2=1.136&f=h - Clear private buffer flags in xfs_vm_invalidatepage to ensure buffers are consistent for reuse after a partial page truncation. From owner-xfs@oss.sgi.com Thu Dec 21 15:32:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 15:32:25 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBLNWIqw025994 for ; Thu, 21 Dec 2006 15:32:20 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA23492; Fri, 22 Dec 2006 10:31:24 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id E16F658CA546; Fri, 22 Dec 2006 10:31:23 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 959388 - use-after-free of inode log item when shutting down a filesystem Message-Id: <20061221233123.E16F658CA546@chook.melbourne.sgi.com> Date: Fri, 22 Dec 2006 10:31:23 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10085 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 594 Lines: 18 Fix inode log item use-after-free on forced shutdown Date: Fri Dec 22 10:30:43 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27805a fs/xfs/xfs_inode.c - 1.457 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.457&r2=text&tr2=1.456&f=h - Remove the inode log item from the AIL list before freeing it on shutdown to prevent it from being used after it has been freed. From owner-xfs@oss.sgi.com Thu Dec 21 15:33:24 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 15:33:29 -0800 (PST) Received: from postoffice.aconex.com (mail.app.aconex.com [203.89.192.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBLNXNqw026283 for ; Thu, 21 Dec 2006 15:33:24 -0800 Received: from edge (unknown [124.178.235.100]) by postoffice.aconex.com (Postfix) with ESMTP id EDE90AAC53C; Fri, 22 Dec 2006 10:24:31 +1100 (EST) Subject: Re: Review: Clear unwritten flag on during partial page truncation From: Nathan Scott Reply-To: nscott@aconex.com To: David Chinner Cc: xfs-dev@sgi.com, xfs@oss.sgi.com In-Reply-To: <20061221113724.GK33919298@melbourne.sgi.com> References: <20061220062813.GU44411608@melbourne.sgi.com> <1166681818.5572.190.camel@edge> <20061221113724.GK33919298@melbourne.sgi.com> Content-Type: text/plain Organization: Aconex Date: Fri, 22 Dec 2006 09:04:58 +1100 Message-Id: <1166738698.5572.194.camel@edge> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-archive-position: 10086 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs Content-Length: 478 Lines: 19 On Thu, 2006-12-21 at 22:37 +1100, David Chinner wrote: > > ... > > the same lines. But alot of effort, with the possibility of it not > > being merged at all, as it touches code outside XFS. D'oh. > > Yep, pretty much my thinking as well. > > I forgot about that hack in xfs_count_page_state() - we should > be able to remove that with this change, right? > Hmm, yes, quite possibly ... worth testing out anyway, but I think you may be right there. cheers. -- Nathan From owner-xfs@oss.sgi.com Thu Dec 21 15:52:46 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 15:52:50 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBLNqgqw028887 for ; Thu, 21 Dec 2006 15:52:45 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA24138; Fri, 22 Dec 2006 10:51:48 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBLNpl7Y70075687; Fri, 22 Dec 2006 10:51:47 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBLNpkHh68008501; Fri, 22 Dec 2006 10:51:46 +1100 (AEDT) Date: Fri, 22 Dec 2006 10:51:46 +1100 From: David Chinner To: xfs-dev@sgi.com Cc: xfs@oss.sgi.com Subject: Review: xfs_start_page_writeback should use clear_page_dirty_for_io Message-ID: <20061221235146.GM33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-archive-position: 10087 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1585 Lines: 49 As has been discuss on LKML w.r.t to an ext3 corruption bug (http://lkml.org/lkml/2006/12/16/164), we should not use clear_page_dirty() as it can result in inconsistent state within the VM and is likely to go away very soon. Instead, we should be using clear_page_dirty_for_io() which does the right thing. Some references: http://lkml.org/lkml/2006/12/20/204 http://lkml.org/lkml/2006/12/20/295 http://lkml.org/lkml/2006/12/20/310 http://lkml.org/lkml/2006/12/20/362 Linus's patch fixes the corruption seen on ARM, so is likely to be merged (potentially as a stable 2.6.19.x fix). That means we rely on set_page_writeback() to set the tag bits in the mapping tree based on whether the page is dirty or not, so we have to call that _after_ we call clear_page_dirty_for_io() instead of before. Comments? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --- fs/xfs/linux-2.6/xfs_aops.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_aops.c 2006-12-19 12:22:47.000000000 +1100 +++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_aops.c 2006-12-21 10:15:04.545375877 +1100 @@ -340,9 +340,9 @@ xfs_start_page_writeback( { ASSERT(PageLocked(page)); ASSERT(!PageWriteback(page)); - set_page_writeback(page); if (clear_dirty) - clear_page_dirty(page); + clear_page_dirty_for_io(page); + set_page_writeback(page); unlock_page(page); if (!buffers) { end_page_writeback(page); From owner-xfs@oss.sgi.com Thu Dec 21 16:32:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 16:32:43 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBM0Waqw004958 for ; Thu, 21 Dec 2006 16:32:38 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08880; Fri, 22 Dec 2006 11:31:42 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBM0Vf7Y65651245; Fri, 22 Dec 2006 11:31:41 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBM0Veiu69954636; Fri, 22 Dec 2006 11:31:40 +1100 (AEDT) Date: Fri, 22 Dec 2006 11:31:40 +1100 From: David Chinner To: David Chinner Cc: xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: xfs_start_page_writeback should use clear_page_dirty_for_io Message-ID: <20061222003140.GN33919298@melbourne.sgi.com> References: <20061221235146.GM33919298@melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061221235146.GM33919298@melbourne.sgi.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 10088 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1068 Lines: 28 On Fri, Dec 22, 2006 at 10:51:46AM +1100, David Chinner wrote: > As has been discuss on LKML w.r.t to an ext3 corruption bug > (http://lkml.org/lkml/2006/12/16/164), we should not use clear_page_dirty() > as it can result in inconsistent state within the VM and is likely > to go away very soon. Instead, we should be using clear_page_dirty_for_io() > which does the right thing. Some references: > > http://lkml.org/lkml/2006/12/20/204 > http://lkml.org/lkml/2006/12/20/295 > http://lkml.org/lkml/2006/12/20/310 > http://lkml.org/lkml/2006/12/20/362 > > Linus's patch fixes the corruption seen on ARM, so is likely to be merged > (potentially as a stable 2.6.19.x fix). FYI, Linus has already commited his patches and this patch to his git tree. http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fba2591bf4e418b6c3f9f8794c9dd8fe40ae7bd9 http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=921320210bd2ec4f17053d283355b73048ac0e56 Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Thu Dec 21 16:46:32 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 21 Dec 2006 16:46:36 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBM0kSqw006952 for ; Thu, 21 Dec 2006 16:46:30 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09438; Fri, 22 Dec 2006 11:45:32 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 5CD4858CA541; Fri, 22 Dec 2006 11:45:32 +1100 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 959485 - xfs_start_page_writeback should use clear_page_dirty_for_io Message-Id: <20061222004532.5CD4858CA541@chook.melbourne.sgi.com> Date: Fri, 22 Dec 2006 11:45:32 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10089 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1221 Lines: 29 Fix XFS after clear_page_dirty() removal XFS appears to call clear_page_dirty to get the mapping tree dirty tag set correctly at the same time the page dirty flag is cleared. I note that this can be done by set_page_writeback() if we clear the dirty flag on the page first when we are writing back the entire page. Hence it seems to me that the XFS call to clear_page_dirty() could easily be substituted by clear_page_dirty_for_io() followed by a call to set_page_writeback() to get the mapping tree tags set correctly after the page has been marked clean. Date: Fri Dec 22 11:44:24 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: torvalds@osdl.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27807a fs/xfs/linux-2.6/xfs_aops.c - 1.138 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.138&r2=text&tr2=1.137&f=h - clear_page_dirty() has been removed from the tree, so use clear_page_dirty_for_io() instead and call set_page_writeback() after modifying the page dirty state to update the mapping tree tags correctly for writeback. From owner-xfs@oss.sgi.com Fri Dec 22 01:51:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 01:51:58 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBM9pkqw005696 for ; Fri, 22 Dec 2006 01:51:49 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA17795; Mon, 18 Dec 2006 09:45:02 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBHMj07Y65056228; Mon, 18 Dec 2006 09:45:01 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBHMivMH64340234; Mon, 18 Dec 2006 09:44:57 +1100 (AEDT) Date: Mon, 18 Dec 2006 09:44:57 +1100 From: David Chinner To: Haar =?iso-8859-1?B?SsOhbm9z?= Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: xfslogd-spinlock bug? Message-ID: <20061217224457.GN33919298@melbourne.sgi.com> References: <003701c71d78$33ed28d0$0400a8c0@dcccs> <00ab01c71e53$942af2f0$0400a8c0@dcccs> <000d01c72127$3d7509b0$0400a8c0@dcccs> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <000d01c72127$3d7509b0$0400a8c0@dcccs> User-Agent: Mutt/1.4.2.1i X-archive-position: 10095 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1922 Lines: 57 On Sat, Dec 16, 2006 at 12:19:45PM +0100, Haar János wrote: > Hi > > I have some news. > > I dont know there is a context between 2 messages, but i can see, the > spinlock bug comes always on cpu #3. > > Somebody have any idea? Your disk interrupts are directed to CPU 3, and so log I/O completion occurs on that CPU. > Dec 16 12:08:36 dy-base BUG: spinlock bad magic on CPU#3, xfslogd/3/317 > Dec 16 12:08:36 dy-base general protection fault: 0000 [1] > Dec 16 12:08:36 dy-base SMP > Dec 16 12:08:36 dy-base > Dec 16 12:08:36 dy-base CPU 3 > Dec 16 12:08:36 dy-base > Dec 16 12:08:36 dy-base Modules linked in: > Dec 16 12:08:36 dy-base nbd Are you using XFS on a NBD? > Dec 16 12:08:36 dy-base rd > Dec 16 12:08:36 dy-base netconsole > Dec 16 12:08:36 dy-base e1000 > Dec 16 12:08:36 dy-base video > Dec 16 12:08:36 dy-base > Dec 16 12:08:36 dy-base Pid: 317, comm: xfslogd/3 Not tainted 2.6.19 #1 > Dec 16 12:08:36 dy-base RIP: 0010:[] > Dec 16 12:08:36 dy-base [] spin_bug+0x69/0xdf > Dec 16 12:08:36 dy-base RSP: 0018:ffff81011fdedbc0 EFLAGS: 00010002 > Dec 16 12:08:36 dy-base RAX: 0000000000000033 RBX: 6b6b6b6b6b6b6b6b RCX: ^^^^^^^^^^^^^^^^ Anyone recognise that pattern? > Dec 16 12:08:36 dy-base Call Trace: > Dec 16 12:08:36 dy-base [] _raw_spin_lock+0x23/0xf1 > Dec 16 12:08:36 dy-base [] _spin_lock_irqsave+0x11/0x18 > Dec 16 12:08:36 dy-base [] __wake_up+0x22/0x50 > Dec 16 12:08:36 dy-base [] xfs_buf_unpin+0x21/0x23 > Dec 16 12:08:36 dy-base [] xfs_buf_item_unpin+0x2e/0xa6 This implies a spinlock inside a wait_queue_head_t is corrupt. What are you type of system do you have, and what sort of workload are you running? Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Fri Dec 22 01:51:37 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 01:51:43 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBM9pWqw005622 for ; Fri, 22 Dec 2006 01:51:35 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA13548; Tue, 21 Nov 2006 10:13:36 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 6420758FF4ED; Tue, 21 Nov 2006 10:13:36 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 958376 - xfs warnings about potential use of uninitialized variables Message-Id: <20061120231336.6420758FF4ED@chook.melbourne.sgi.com> Date: Tue, 21 Nov 2006 10:13:36 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10092 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 562 Lines: 17 Stale the correct inode when freeing clusters. Date: Tue Nov 21 10:11:46 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27503a fs/xfs/xfs_inode.c - 1.455 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.455&r2=text&tr2=1.454&f=h - Fix xfs_ifree_cluster to stale the correct inode when walking the log items attached to the cluster buffer. From owner-xfs@oss.sgi.com Fri Dec 22 01:51:41 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 01:51:46 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBM9pWr0005622 for ; Fri, 22 Dec 2006 01:51:39 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12844; Thu, 23 Nov 2006 14:32:03 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 1239A58FF50E; Thu, 23 Nov 2006 14:32:03 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 957195 - system wedged in xfs_write / xfs_buf_lock Message-Id: <20061123033203.1239A58FF50E@chook.melbourne.sgi.com> Date: Thu, 23 Nov 2006 14:32:03 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 10093 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1513 Lines: 38 Fix a synchronous buftarg flush deadlock when freezing. At the last stage of a freeze, we flush the buftarg synchronously over and over again until it succeeds twice without skipping any buffers. The delwri list flush skips pinned buffers, but tries to flush all others. It removes the buffers from the delwri list, then tries to lock them one at a time as it traverses the list to issue the I/O. It holds them locked until we issue all of the I/O and then unlocks them once we've waited for it to complete. The problem is that during a freeze, the filesystem may still be doing stuff - like flushing delalloc data buffers - in the background and hence we can be trying to lock buffers that were on the delwri list at the same time. Hence we can get ABBA deadlocks between threads doing allocation and the buftarg flush (freeze) thread. Fix it by skipping locked (and pinned) buffers as we traverse the delwri buffer list. Date: Thu Nov 23 14:30:57 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:27535a fs/xfs/linux-2.6/xfs_buf.c - 1.230 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_buf.c.diff?r1=text&tr1=1.230&r2=text&tr2=1.229&f=h - Skip locked buffers when flushing the buftarg delwri buffer list to prevent deadlocks with allocation when synchronously flushing the buftarg during a freeze. From owner-xfs@oss.sgi.com Fri Dec 22 01:51:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 01:51:47 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBM9pZqw005632 for ; Fri, 22 Dec 2006 01:51:37 -0800 Received: from [134.14.55.84] (shark.melbourne.sgi.com [134.14.55.84]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA17990; Wed, 29 Nov 2006 10:55:35 +1100 Message-ID: <456CCC77.7000001@sgi.com> Date: Wed, 29 Nov 2006 10:55:35 +1100 From: Donald Douwsma User-Agent: Thunderbird 1.5.0.8 (X11/20060911) MIME-Version: 1.0 To: Rene Salmon CC: xfs@oss.sgi.com Subject: Re: get xfs_quota info as regular user References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10094 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Content-Length: 775 Lines: 28 Rene Salmon wrote: > Hi, > > > Did some searches on the list archives but could not find any useful info on > this. > > Is there a way for a regular user to get info about his or her quota usage? > > I tried both of these as a regular user and get nothing: > > 120> xfs_quota -c "quota userid" > 121> xfs_quota -x -c "quota userid" By default the quota command does not display anything unless the user is overquota. To display the limits set for a user you need to specify the -v option. xfs_quota -c 'quota -v' Note there is currently a bug in xfs-cmds that causes xfs_quota to display results multiple times (once for each xfs filesystem). One work around for this is to specify the specific filesystem on the commandline. xfs_quota -c 'quota -v' /home Donald From owner-xfs@oss.sgi.com Fri Dec 22 01:52:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 01:52:19 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBM9q1r0005815 for ; Fri, 22 Dec 2006 01:52:06 -0800 Received: from [134.15.251.1] ([134.15.251.1]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA17734; Wed, 22 Nov 2006 08:53:45 +1100 Message-ID: <45637566.5020802@melbourne.sgi.com> Date: Wed, 22 Nov 2006 08:53:42 +1100 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Jesper Juhl CC: LKML , xfs@oss.sgi.com, xfs-masters@oss.sgi.com, netdev@vger.kernel.org, linux-scsi@vger.kernel.org Subject: Re: 2.6.19-rc6 : Spontaneous reboots, stack overflows - seems to implicate xfs, scsi, networking, SMP References: <200611211027.41971.jesper.juhl@gmail.com> In-Reply-To: <200611211027.41971.jesper.juhl@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10096 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 55642 Lines: 1257 Jesper, In the short term, the best workaround is to use 8K stacks. We do not see stack overflow problems with NFS + XFS + volume managers + disk devices. Audits have been done in the past and will again be done in the future to try to identify areas where XFS could use less stack space by reducing/avoid large local variables. Reducing the code path is far more difficult. There is active discussion about reducing inlining: http://bugzilla.kernel.org/show_bug.cgi?id=7364 I can't speak for the scsi stack usage. Thanks for traces, I've captured this information. Thanks, David Jesper Juhl wrote: > Hi, > > I have a server that has long suffered from spontaneous reboots and random > crashes. > The problems seem to be partly SMP related since the machine is rock solid > with a UP version of 2.6.11.11, but the same kernel compiled for SMP has > issues. > > The server initially had 1 Intel Xeon CPU with HT and was very recently > upgraded with an additional one (in the blind hope that the issues would be > fixed). The kernel *seems* to die faster with 2 CPU's and a SMP kernel than > it previously did with just one (HT) CPU and a SMP kernel. > > I've been trying newer kernels, such as 2.6.17.x, 2.6.18.x, 2.6.19-rc* > (all SMP), hoping that the problem(s) would be fixed, but that does not seem > to be the case. > > Recently I've been using netconsole and have lots of debug options enabled > in the hope that I could capture some relevant info. Unfortunately nothing > ever really made it to the remote log - except one little incomplete bit I > got the other day (with 2.6.19-rc6) : > > do_IRQ: stack overflow: 492 > > That is all that made it to the log, but it does indicate that the problem > might be stack-usage related. > Since the kernel was compiled with 4K stacks, perhaps if it was changed to > use 8K stacks it would stay up long enough for a complete dump to reach the > logs. But, if 8K stacks really did help, it would be nice if the dumps still > happened at the same point where they would have with 4K stacks. > So, I changed STACK_WARN in include/asm/thread_info.h from (THREAD_SIZE/8) > to(4608). This way I should get stack traces at the point where the kernel > would be in trouble with a 4K stack but since it's actually using a 8K stack > it should survive and let me capture the trace. > > I got more than I could ever have hoped for. I still got spontaneous > reboots, but this time my remote log server captured tons of stack dumps. > I've got far too many to send here (more than 2G) and most of them are > identical anyway, so I'll just submit a few representative samples > initially. > > Most of the traces include XFS functions and some also involve scsi and/or > networking. This is the reason I'm submitting this to the XFS & netdev lists > in addition to LKML. > > All of these traces were collected with 2.6.19-rc6 with the modification > mentioned above. > > Hardware details and software environment info is at the end of the email. > > > This is the most often captured trace : > > do_IRQ: stack overflow: 4416 > [] dump_trace+0x1e7/0x1fd > [] show_trace_log_lvl+0x1c/0x33 > [] show_trace+0x12/0x16 > [] dump_stack+0x19/0x1d > [] do_IRQ+0xaf/0xd6 > [] common_interrupt+0x1a/0x20 > [] __do_softirq+0x59/0xd0 > [] do_softirq+0x37/0x39 > [] irq_exit+0x39/0x3b > [] do_IRQ+0x74/0xd6 > [] common_interrupt+0x1a/0x20 > [] make_request+0x320/0x426 > [] generic_make_request+0x14f/0x1b7 > [] __map_bio+0x4c/0x93 > [] __clone_and_map+0xdb/0x30a > [] __split_bio+0xa4/0xc7 > [] dm_request+0xa0/0xbf > [] generic_make_request+0x14f/0x1b7 > [] submit_bio+0x68/0x109 > [] _xfs_buf_ioapply+0x1cf/0x28d > [] xfs_buf_iorequest+0x29/0x6e > [] xlog_bdstrat_cb+0x19/0x41 > [] xlog_sync+0x24e/0x457 > [] xlog_state_release_iclog+0x75/0xd0 > [] xlog_state_sync+0x175/0x269 > [] _xfs_log_force+0x7f/0x88 > [] xfs_alloc_search_busy+0xdf/0xe1 > [] xfs_alloc_get_freelist+0xe7/0xf5 > [] xfs_alloc_newroot+0x21/0x34f > [] xfs_alloc_insrec+0x3b0/0x3ce > [] xfs_alloc_insert+0x5a/0xc3 > [] xfs_free_ag_extent+0x57f/0x5f2 > [] xfs_alloc_fix_freelist+0x220/0x45c > [] xfs_alloc_vextent+0x24e/0x47a > [] xfs_bmap_btalloc+0x31f/0x966 > [] xfs_bmap_alloc+0x1e/0x29 > [] xfs_bmapi+0x1134/0x1545 > [] xfs_iomap_write_allocate+0x2bb/0x509 > [] xfs_iomap+0x357/0x459 > [] xfs_bmap+0x2e/0x35 > [] xfs_map_blocks+0x3c/0x70 > [] xfs_page_state_convert+0x3cc/0x629 > [] xfs_vm_writepage+0x5c/0xd3 > [] generic_writepages+0x1b9/0x2d5 > [] xfs_vm_writepages+0x24/0x4a > [] do_writepages+0x2a/0x46 > [] __sync_single_inode+0x5c/0x1de > [] __writeback_single_inode+0x85/0x18f > [] sync_sb_inodes+0x1b3/0x2b2 > [] writeback_inodes+0xb2/0xbe > [] background_writeout+0x66/0x9a > [] __pdflush+0xcf/0x184 > [] pdflush+0x32/0x36 > [] kthread+0xa9/0xae > [] kernel_thread_helper+0x7/0x10 > > another very common one is this one : > > do_IRQ: stack overflow: 4532 > [] dump_trace+0x1e7/0x1fd > [] show_trace_log_lvl+0x1c/0x33 > [] show_trace+0x12/0x16 > [] dump_stack+0x19/0x1d > [] do_IRQ+0xaf/0xd6 > [] common_interrupt+0x1a/0x20 > [] xfs_buf_bio_end_io+0xd9/0x11f > [] bio_endio+0x55/0x7a > [] dec_pending+0x3d/0x6b > [] clone_endio+0x85/0xb1 > [] bio_endio+0x55/0x7a > [] __end_that_request_first+0x1df/0x271 > [] end_that_request_chunk+0x8/0xa > [] scsi_end_request+0x25/0xcb > [] scsi_io_completion+0x82/0x301 > [] sd_rw_intr+0x76/0x20f > [] scsi_finish_command+0x43/0x5e > [] scsi_softirq_done+0x70/0xd5 > [] blk_done_softirq+0x62/0x6b > [] __do_softirq+0xbb/0xd0 > [] do_softirq+0x37/0x39 > [] irq_exit+0x39/0x3b > [] do_IRQ+0x74/0xd6 > [] common_interrupt+0x1a/0x20 > [] mempool_alloc+0x21/0xce > [] bio_alloc_bioset+0x79/0x13f > [] clone_bio+0x36/0x7d > [] __clone_and_map+0xce/0x30a > [] __split_bio+0xa4/0xc7 > [] dm_request+0xa0/0xbf > [] generic_make_request+0x14f/0x1b7 > [] submit_bio+0x68/0x109 > [] _xfs_buf_ioapply+0x1cf/0x28d > [] xfs_buf_iorequest+0x29/0x6e > [] xfs_buf_iostart+0x6d/0x97 > [] xfs_buf_read_flags+0x8a/0x8c > [] xfs_trans_read_buf+0x153/0x2fc > [] xfs_btree_read_bufs+0x6e/0x84 > [] xfs_alloc_lookup+0x10a/0x39e > [] xfs_alloc_lookup_ge+0x17/0x1a > [] xfs_alloc_ag_vextent_near+0x5f/0x957 > [] xfs_alloc_ag_vextent+0x104/0x106 > [] xfs_alloc_vextent+0x372/0x47a > [] xfs_bmap_btalloc+0x31f/0x966 > [] xfs_bmap_alloc+0x1e/0x29 > [] xfs_bmapi+0x1134/0x1545 > [] xfs_iomap_write_allocate+0x2bb/0x509 > [] xfs_iomap+0x357/0x459 > [] xfs_bmap+0x2e/0x35 > [] xfs_map_blocks+0x3c/0x70 > [] xfs_page_state_convert+0x3cc/0x629 > [] xfs_vm_writepage+0x5c/0xd3 > [] generic_writepages+0x1b9/0x2d5 > [] xfs_vm_writepages+0x24/0x4a > [] do_writepages+0x2a/0x46 > [] __sync_single_inode+0x5c/0x1de > [] __writeback_single_inode+0x85/0x18f > [] sync_sb_inodes+0x1b3/0x2b2 > [] writeback_inodes+0xb2/0xbe > [] wb_kupdate+0x80/0xe9 > [] __pdflush+0xcf/0x184 > [] pdflush+0x32/0x36 > [] kthread+0xa9/0xae > [] kernel_thread_helper+0x7/0x10 > > This one seems to involve scsi : > > do_IRQ: stack overflow: 4568 > [] dump_trace+0x1e7/0x1fd > [] show_trace_log_lvl+0x1c/0x33 > [] show_trace+0x12/0x16 > [] dump_stack+0x19/0x1d > [] do_IRQ+0xaf/0xd6 > [] common_interrupt+0x1a/0x20 > [] _spin_unlock_irq+0xa/0xb > [] blk_run_queue+0x42/0x77 > [] scsi_run_queue+0xc9/0xf1 > [] scsi_next_command+0x33/0x49 > [] scsi_end_request+0xb0/0xcb > [] scsi_io_completion+0x82/0x301 > [] sd_rw_intr+0x76/0x20f > [] scsi_finish_command+0x43/0x5e > [] scsi_softirq_done+0x70/0xd5 > [] blk_done_softirq+0x62/0x6b > [] __do_softirq+0xbb/0xd0 > [] do_softirq+0x37/0x39 > [] irq_exit+0x39/0x3b > [] do_IRQ+0x74/0xd6 > [] common_interrupt+0x1a/0x20 > [] _spin_unlock_irq+0xa/0xb > [] generic_make_request+0x14f/0x1b7 > [] __map_bio+0x4c/0x93 > [] __clone_and_map+0xdb/0x30a > [] __split_bio+0xa4/0xc7 > [] dm_request+0xa0/0xbf > [] generic_make_request+0x14f/0x1b7 > [] submit_bio+0x68/0x109 > [] _xfs_buf_ioapply+0x1cf/0x28d > [] xfs_buf_iorequest+0x29/0x6e > [] xfs_buf_iostart+0x6d/0x97 > [] xfs_buf_read_flags+0x8a/0x8c > [] xfs_trans_read_buf+0x153/0x2fc > [] xfs_btree_read_bufs+0x6e/0x84 > [] xfs_alloc_lookup+0x10a/0x39e > [] xfs_alloc_lookup_eq+0x14/0x17 > [] xfs_alloc_fixup_trees+0x252/0x2a9 > [] xfs_alloc_ag_vextent_size+0x318/0x405 > [] xfs_alloc_ag_vextent+0xe2/0x106 > [] xfs_alloc_vextent+0x372/0x47a > [] xfs_bmap_btalloc+0x31f/0x966 > [] xfs_bmap_alloc+0x1e/0x29 > [] xfs_bmapi+0x1134/0x1545 > [] xfs_iomap_write_allocate+0x2bb/0x509 > [] xfs_iomap+0x357/0x459 > [] xfs_bmap+0x2e/0x35 > [] xfs_map_blocks+0x3c/0x70 > [] xfs_page_state_convert+0x3cc/0x629 > [] xfs_vm_writepage+0x5c/0xd3 > [] generic_writepages+0x1b9/0x2d5 > [] xfs_vm_writepages+0x24/0x4a > [] do_writepages+0x2a/0x46 > [] __sync_single_inode+0x5c/0x1de > [] __writeback_single_inode+0x85/0x18f > [] sync_sb_inodes+0x1b3/0x2b2 > [] writeback_inodes+0xb2/0xbe > [] background_writeout+0x66/0x9a > [] __pdflush+0xcf/0x184 > [] pdflush+0x32/0x36 > [] kthread+0xa9/0xae > [] kernel_thread_helper+0x7/0x10 > > And then there are some where stack space is really low, which would > certainly have killed us if running with 4K stacks : > > First this : > > do_IRQ: stack overflow: 3376 > [] dump_trace+0x1e7/0x1fd > [] show_trace_log_lvl+0x1c/0x33 > [] show_trace+0x12/0x16 > [] dump_stack+0x19/0x1d > [] do_IRQ+0xaf/0xd6 > [] common_interrupt+0x1a/0x20 > [] _spin_unlock_irqrestore+0xd/0x10 > [] e1000_xmit_frame+0x269/0x3b1 > [] dev_hard_start_xmit+0x5a/0xd3 > [] __qdisc_run+0x95/0x1d7 > [] dev_queue_xmit+0x220/0x285 > [] vlan_dev_hwaccel_hard_start_xmit+0x8a/0x92 > [] dev_hard_start_xmit+0x5a/0xd3 > [] dev_queue_xmit+0x15f/0x285 > [] neigh_connected_output+0x93/0xba > [] ip_output+0x170/0x250 > [] ip_queue_xmit+0x3d8/0x4e1 > [] tcp_transmit_skb+0x29e/0x45d > [] tcp_send_ack+0xb3/0xf4 > [] tcp_send_dupack+0x28/0x7f > [] tcp_rcv_established+0x141/0x6c8 > [] tcp_v4_do_rcv+0xcb/0xcd > [] tcp_v4_rcv+0x673/0x7e3 > [] ip_local_deliver+0xf8/0x22d > [] ip_rcv+0x244/0x4e4 > [] netif_receive_skb+0x1f9/0x26a > [] e1000_clean_rx_irq+0x17f/0x4b9 > [] e1000_clean+0x66/0xfb > [] net_rx_action+0x96/0x174 > [] __do_softirq+0xbb/0xd0 > [] do_softirq+0x37/0x39 > [] irq_exit+0x39/0x3b > [] do_IRQ+0x74/0xd6 > [] common_interrupt+0x1a/0x20 > [] max_io_len+0x15/0x88 > [] __clone_and_map+0x44/0x30a > [] __split_bio+0xa4/0xc7 > [] dm_request+0xa0/0xbf > [] generic_make_request+0x14f/0x1b7 > [] submit_bio+0x68/0x109 > [] _xfs_buf_ioapply+0x1cf/0x28d > [] xfs_buf_iorequest+0x29/0x6e > [] xfs_buf_iostart+0x6d/0x97 > [] xfs_buf_read_flags+0x8a/0x8c > [] xfs_trans_read_buf+0x153/0x2fc > [] xfs_btree_read_bufs+0x6e/0x84 > [] xfs_alloc_lookup+0x10a/0x39e > [] xfs_alloc_lookup_ge+0x17/0x1a > [] xfs_alloc_ag_vextent_near+0x5f/0x957 > [] xfs_alloc_ag_vextent+0x104/0x106 > [] xfs_alloc_vextent+0x372/0x47a > [] xfs_bmap_btalloc+0x31f/0x966 > [] xfs_bmap_alloc+0x1e/0x29 > [] xfs_bmapi+0x1134/0x1545 > [] xfs_iomap_write_allocate+0x2bb/0x509 > [] xfs_iomap+0x357/0x459 > [] xfs_bmap+0x2e/0x35 > [] xfs_map_blocks+0x3c/0x70 > [] xfs_page_state_convert+0x3cc/0x629 > [] xfs_vm_writepage+0x5c/0xd3 > [] generic_writepages+0x1b9/0x2d5 > [] xfs_vm_writepages+0x24/0x4a > [] do_writepages+0x2a/0x46 > [] __sync_single_inode+0x5c/0x1de > [] __writeback_single_inode+0x85/0x18f > [] sync_sb_inodes+0x1b3/0x2b2 > [] writeback_inodes+0xb2/0xbe > [] balance_dirty_pages+0xa6/0x15c > [] balance_dirty_pages_ratelimited_nr+0x59/0x5b > [] generic_file_buffered_write+0x2ef/0x61f > [] xfs_write+0x96f/0xb1c > [] xfs_file_aio_write+0x78/0x8a > [] do_sync_write+0xc1/0x100 > [] vfs_write+0x91/0x137 > [] sys_write+0x41/0x6b > [] syscall_call+0x7/0xb > [] 0xb7f6b95e > > and this : > > e1000: eth0: e1000_clean_tx_irq: Detected Tx Unit Hang > Tx Queue <0> > TDH > TDT > next_to_use > next_to_clean > buffer_info[next_to_clean] > time_stamp > next_to_watch > jiffies > next_to_watch.status <1> > do_IRQ: stack overflow: 3836 > [] dump_trace+0x1e7/0x1fd > [] show_trace_log_lvl+0x1c/0x33 > [] show_trace+0x12/0x16 > [] dump_stack+0x19/0x1d > [] do_IRQ+0xaf/0xd6 > [] common_interrupt+0x1a/0x20 > [] csum_partial+0xb8/0x120 > DWARF2 unwinder stuck at csum_partial+0xb8/0x120 > Leftover inexact backtrace: > [] __skb_checksum_complete+0x20/0x67 > [] nf_ip_checksum+0xe0/0x125 > [] udp_error+0x105/0x184 > [] ip_conntrack_in+0x7d/0x294 > [] nf_iterate+0x62/0x7c > [] nf_hook_slow+0x58/0xbf > [] ip_rcv+0x40c/0x4e4 > [] netif_receive_skb+0x1f9/0x26a > [] e1000_clean_rx_irq+0x17f/0x4b9 > [] e1000_clean+0x66/0xfb > [] net_rx_action+0x96/0x174 > [] __do_softirq+0xbb/0xd0 > [] do_softirq+0x37/0x39 > [] irq_exit+0x39/0x3b > [] do_IRQ+0x74/0xd6 > [] common_interrupt+0x1a/0x20 > [] __clone_and_map+0x44/0x30a > [] __split_bio+0xa4/0xc7 > [] dm_request+0xa0/0xbf > [] generic_make_request+0x14f/0x1b7 > [] submit_bio+0x68/0x109 > [] _xfs_buf_ioapply+0x1cf/0x28d > [] xfs_buf_iorequest+0x29/0x6e > [] xfs_buf_iostart+0x6d/0x97 > [] xfs_buf_read_flags+0x8a/0x8c > [] xfs_trans_read_buf+0x153/0x2fc > [] xfs_btree_read_bufs+0x6e/0x84 > [] xfs_alloc_lookup+0x10a/0x39e > [] xfs_alloc_lookup_ge+0x17/0x1a > [] xfs_alloc_ag_vextent_near+0x5f/0x957 > [] xfs_alloc_ag_vextent+0x104/0x106 > [] xfs_alloc_vextent+0x372/0x47a > [] xfs_bmap_btalloc+0x31f/0x966 > [] xfs_bmap_alloc+0x1e/0x29 > [] xfs_bmapi+0x1134/0x1545 > [] xfs_iomap_write_allocate+0x2bb/0x509 > [] xfs_iomap+0x357/0x459 > [] xfs_bmap+0x2e/0x35 > [] xfs_map_blocks+0x3c/0x70 > [] xfs_page_state_convert+0x3cc/0x629 > [] xfs_vm_writepage+0x5c/0xd3 > [] generic_writepages+0x1b9/0x2d5 > [] xfs_vm_writepages+0x24/0x4a > [] do_writepages+0x2a/0x46 > [] __sync_single_inode+0x5c/0x1de > [] __writeback_single_inode+0x85/0x18f > [] sync_sb_inodes+0x1b3/0x2b2 > [] writeback_inodes+0xb2/0xbe > [] balance_dirty_pages+0xa6/0x15c > [] balance_dirty_pages_ratelimited_nr+0x59/0x5b > [] generic_file_buffered_write+0x2ef/0x61f > [] xfs_write+0x96f/0xb1c > [] xfs_file_aio_write+0x78/0x8a > [] do_sync_write+0xc1/0x100 > [] vfs_write+0x91/0x137 > [] sys_write+0x41/0x6b > [] syscall_call+0x7/0xb > > and finally this one : > > do_IRQ: stack overflow: 3916 > [] dump_trace+0x1e7/0x1fd > [] show_trace_log_lvl+0x1c/0x33 > [] show_trace+0x12/0x16 > [] dump_stack+0x19/0x1d > [] do_IRQ+0xaf/0xd6 > [] common_interrupt+0x1a/0x20 > [] tcp_init_tso_segs+0x17/0x4c > [] tcp_write_xmit+0x5d/0x266 > [] __tcp_push_pending_frames+0x29/0x81 > [] tcp_rcv_established+0x208/0x6c8 > [] tcp_v4_do_rcv+0xcb/0xcd > [] tcp_v4_rcv+0x673/0x7e3 > [] ip_local_deliver+0xf8/0x22d > [] ip_rcv+0x244/0x4e4 > [] netif_receive_skb+0x1f9/0x26a > [] e1000_clean_rx_irq+0x17f/0x4b9 > [] e1000_clean+0x66/0xfb > [] net_rx_action+0x96/0x174 > [] __do_softirq+0xbb/0xd0 > [] do_softirq+0x37/0x39 > [] irq_exit+0x39/0x3b > [] do_IRQ+0x74/0xd6 > [] common_interrupt+0x1a/0x20 > [] max_io_len+0x15/0x88 > [] __clone_and_map+0x44/0x30a > [] __split_bio+0xa4/0xc7 > [] dm_request+0xa0/0xbf > [] generic_make_request+0x14f/0x1b7 > [] submit_bio+0x68/0x109 > [] _xfs_buf_ioapply+0x1cf/0x28d > [] xfs_buf_iorequest+0x29/0x6e > [] xfs_buf_iostart+0x6d/0x97 > [] xfs_buf_read_flags+0x8a/0x8c > [] xfs_trans_read_buf+0x153/0x2fc > [] xfs_btree_read_bufs+0x6e/0x84 > [] xfs_alloc_lookup+0x10a/0x39e > [] xfs_alloc_lookup_ge+0x17/0x1a > [] xfs_alloc_ag_vextent_near+0x5f/0x957 > [] xfs_alloc_ag_vextent+0x104/0x106 > [] xfs_alloc_vextent+0x372/0x47a > [] xfs_bmap_btalloc+0x31f/0x966 > [] xfs_bmap_alloc+0x1e/0x29 > [] xfs_bmapi+0x1134/0x1545 > [] xfs_iomap_write_allocate+0x2bb/0x509 > [] xfs_iomap+0x357/0x459 > [] xfs_bmap+0x2e/0x35 > [] xfs_map_blocks+0x3c/0x70 > [] xfs_page_state_convert+0x3cc/0x629 > [] xfs_vm_writepage+0x5c/0xd3 > [] generic_writepages+0x1b9/0x2d5 > [] xfs_vm_writepages+0x24/0x4a > [] do_writepages+0x2a/0x46 > [] __sync_single_inode+0x5c/0x1de > [] __writeback_single_inode+0x85/0x18f > [] sync_sb_inodes+0x1b3/0x2b2 > [] writeback_inodes+0xb2/0xbe > [] balance_dirty_pages+0xa6/0x15c > [] balance_dirty_pages_ratelimited_nr+0x59/0x5b > [] generic_file_buffered_write+0x2ef/0x61f > [] xfs_write+0x96f/0xb1c > [] xfs_file_aio_write+0x78/0x8a > [] do_sync_write+0xc1/0x100 > [] vfs_write+0x91/0x137 > [] sys_write+0x41/0x6b > [] syscall_call+0x7/0xb > [] 0xb7f6b95e > > And there are lots of other ones as well that differ slightly from the ones > above. > > > Some hardware/software details : > > # scripts/ver_linux > If some fields are empty or look unusual you may have an old version. > Compare to the current minimal requirements in Documentation/Changes. > > Linux server.mydomain.net 2.6.19-rc6 #1 SMP Mon Nov 20 14:33:26 CET 2006 i686 > GNU/Linux > > Gnu C 3.3.5 > Gnu make 3.80 > binutils 2.15 > util-linux 2.12p > mount 2.12p > module-init-tools 3.2-pre1 > e2fsprogs 1.37 > xfsprogs 2.6.20 > nfs-utils 1.0.6 > Linux C Library 2.3.2 > Dynamic linker (ldd) 2.3.2 > Procps 3.2.1 > Net-tools 1.60 > Console-tools 0.2.3 > Sh-utils 5.2.1 > udev 056 > Modules Loaded sky2 piix ide_core eeprom > > # lspci -vvx > 0000:00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 0c) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Capabilities: [40] #09 [4105] > 00: 86 80 90 35 46 01 90 00 0c 00 00 06 00 00 80 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 40 00 00 00 00 00 00 00 00 00 00 00 > > 0000:00:00.1 ff00: Intel Corp. Memory Controller Hub Error Reporting Register > (rev 0c) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- 00: 86 80 91 35 00 01 00 00 0c 00 00 ff 00 00 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 0000:00:01.0 System peripheral: Intel Corp. Memory Controller Hub DMA > Controller (rev 0c) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Interrupt: pin A routed to IRQ 10 > Region 0: Memory at fcbff000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [b0] Message Signalled Interrupts: 64bit- Queue=0/1 > Enable- > Address: fee00000 Data: 0000 > 00: 86 80 94 35 02 01 10 00 0c 00 80 08 00 00 00 00 > 10: 00 f0 bf fc 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 b0 00 00 00 00 00 00 00 0a 01 00 00 > > 0000:00:02.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port A0 > (rev 0c) (prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 0x10 (64 bytes) > Bus: primary=00, secondary=01, subordinate=03, sec-latency=0 > I/O behind bridge: 0000b000-0000cfff > Memory behind bridge: fcc00000-fcefffff > Prefetchable memory behind bridge: 00000000fa000000-00000000fb700000 > BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 > Enable- > Address: fee00000 Data: 0000 > Capabilities: [64] #10 [0041] > 00: 86 80 95 35 47 01 10 00 0c 00 04 06 10 00 01 00 > 10: 00 00 00 00 00 00 00 00 00 01 03 00 b0 c0 00 00 > 20: c0 fc e0 fc 01 fa 71 fb 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 06 00 > > 0000:00:04.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B0 > (rev 0c) (prog-if 00 [Normal decode]) > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 0x10 (64 bytes) > Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 > BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 > Enable- > Address: fee00000 Data: 0000 > Capabilities: [64] #10 [0041] > 00: 86 80 97 35 44 01 10 00 0c 00 04 06 10 00 01 00 > 10: 00 00 00 00 00 00 00 00 00 04 04 00 f0 00 00 20 > 20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 06 00 > > 0000:00:05.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B1 > (rev 0c) (prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 0x10 (64 bytes) > Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 > I/O behind bridge: 0000d000-0000dfff > Memory behind bridge: fcf00000-fcffffff > BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 > Enable- > Address: fee00000 Data: 0000 > Capabilities: [64] #10 [0041] > 00: 86 80 98 35 47 01 18 00 0c 00 04 06 10 00 01 00 > 10: 00 00 00 00 00 00 00 00 00 05 05 00 d0 d0 00 00 > 20: f0 fc f0 fc f1 ff 01 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 07 00 > > 0000:00:06.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port C0 > (rev 0c) (prog-if 00 [Normal decode]) > Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 0x10 (64 bytes) > Bus: primary=00, secondary=06, subordinate=06, sec-latency=0 > BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] Message Signalled Interrupts: 64bit- Queue=0/1 > Enable- > Address: fee00000 Data: 0000 > Capabilities: [64] #10 [0041] > 00: 86 80 99 35 44 01 10 00 0c 00 04 06 10 00 01 00 > 10: 00 00 00 00 00 00 00 00 00 06 06 00 f0 00 00 20 > 20: f0 ff 00 00 f1 ff 01 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 06 00 > > 0000:00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 > (rev 02) (prog-if 00 [UHCI]) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > Interrupt: pin A routed to IRQ 10 > Region 4: I/O ports at a880 [size=32] > 00: 86 80 d2 24 05 00 80 02 02 00 03 0c 00 00 80 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 81 a8 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 0a 01 00 00 > > 0000:00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 > (rev 02) (prog-if 00 [UHCI]) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > Interrupt: pin B routed to IRQ 7 > Region 4: I/O ports at ac00 [size=32] > 00: 86 80 d4 24 05 00 80 02 02 00 03 0c 00 00 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 01 ac 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 07 02 00 00 > > 0000:00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 > (rev 02) (prog-if 00 [UHCI]) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > Interrupt: pin C routed to IRQ 15 > Region 4: I/O ports at ac80 [size=32] > 00: 86 80 d7 24 05 00 80 02 02 00 03 0c 00 00 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 81 ac 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 03 00 00 > > 0000:00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI > Controller (rev 02) (prog-if 20 [EHCI]) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > Interrupt: pin D routed to IRQ 21 > Region 0: Memory at fcbfec00 (32-bit, non-prefetchable) [size=1K] > Capabilities: [50] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] #0a [20a0] > 00: 86 80 dd 24 06 01 90 02 02 20 03 0c 00 00 00 00 > 10: 00 ec bf fc 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 50 00 00 00 00 00 00 00 05 04 00 00 > > 0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) (prog-if 00 > [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Bus: primary=00, secondary=07, subordinate=07, sec-latency=32 > I/O behind bridge: 0000e000-0000efff > Memory behind bridge: fd000000-febfffff > Prefetchable memory behind bridge: fb800000-fbffffff > BridgeCtl: Parity+ SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B- > 00: 86 80 4e 24 47 01 80 00 c2 00 04 06 00 00 01 00 > 10: 00 00 00 00 00 00 00 00 00 07 07 20 e0 e0 80 02 > 20: 00 fd b0 fe 80 fb f0 fb 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0b 00 > > 0000:00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev > 02) > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > 00: 86 80 d0 24 4f 01 80 02 02 00 01 06 00 00 80 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > > 0000:00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 > Storage Controller (rev 02) (prog-if 8a [Master SecP PriP]) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > Interrupt: pin A routed to IRQ 20 > Region 0: I/O ports at > Region 1: I/O ports at > Region 2: I/O ports at > Region 3: I/O ports at > Region 4: I/O ports at fc00 [size=16] > Region 5: Memory at 88000000 (32-bit, non-prefetchable) [size=1K] > 00: 86 80 db 24 07 00 88 02 02 8a 01 01 00 00 00 00 > 10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00 > 20: 01 fc 00 00 00 00 00 88 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 > > 0000:00:1f.2 IDE interface: Intel Corp. 82801EB (ICH5) Serial ATA 150 Storage > Controller (rev 02) (prog-if 8f [Master SecP SecO PriP PriO]) > Subsystem: Intel Corp.: Unknown device 3460 > Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR- FastB2B- > Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 0 > Interrupt: pin A routed to IRQ 20 > Region 0: I/O ports at a800 [size=8] > Region 1: I/O ports at a480 [size=4] > Region 2: I/O ports at a400 [size=8] > Region 3: I/O ports at a080 [size=4] > Region 4: I/O ports at a000 [size=16] > 00: 86 80 d1 24 45 00 a0 02 02 8f 01 01 00 00 00 00 > 10: 01 a8 00 00 81 a4 00 00 01 a4 00 00 81 a0 00 00 > 20: 01 a0 00 00 00 00 00 00 00 00 00 00 86 80 60 34 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 0f 01 00 00 > > 0000:00:1f.3 SMBus: Intel Corp. 82801EB/ER (ICH5/ICH5R) SMBus Controller (rev > 02) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping- SERR- FastB2B- > Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Interrupt: pin B routed to IRQ 22 > Region 4: I/O ports at 0540 [size=32] > 00: 86 80 d3 24 01 00 80 02 02 00 05 0c 00 00 00 00 > 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 41 05 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 00 00 00 00 00 00 00 00 0b 02 00 00 > > 0000:01:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09) (prog-if 00 > [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 0x10 (64 bytes) > Bus: primary=01, secondary=02, subordinate=02, sec-latency=48 > I/O behind bridge: 0000b000-0000bfff > Memory behind bridge: fcd00000-fcdfffff > Prefetchable memory behind bridge: 00000000fa000000-00000000faf00000 > BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- > Capabilities: [44] #10 [0071] > Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0 > Enable- > Address: 0000000000000000 Data: 0000 > Capabilities: [6c] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [d8] 00: 86 80 29 03 47 01 10 00 09 00 04 06 10 00 81 00 > 10: 00 00 00 00 00 00 00 00 01 02 02 30 b0 b0 a0 02 > 20: d0 fc d0 fc 01 fa f1 fa 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 07 00 > > 0000:01:00.1 PIC: Intel Corp. PCI Bridge Hub I/OxAPIC Interrupt Controller A > (rev 09) (prog-if 20 [IO(X)-APIC]) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Region 0: Memory at fccfe000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [44] #10 [0001] > Capabilities: [6c] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 00: 86 80 26 03 46 01 10 00 09 20 00 08 00 00 80 00 > 10: 00 e0 cf fc 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 00 00 > > 0000:01:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09) (prog-if 00 > [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 0x10 (64 bytes) > Bus: primary=01, secondary=03, subordinate=03, sec-latency=48 > I/O behind bridge: 0000c000-0000cfff > Memory behind bridge: fce00000-fcefffff > Prefetchable memory behind bridge: 00000000fb000000-00000000fb700000 > BridgeCtl: Parity+ SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B- > Capabilities: [44] #10 [0071] > Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/0 > Enable- > Address: 0000000000000000 Data: 0000 > Capabilities: [6c] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [d8] 00: 86 80 2a 03 47 01 10 00 09 00 04 06 10 00 81 00 > 10: 00 00 00 00 00 00 00 00 01 03 03 30 c0 c0 a0 02 > 20: e0 fc e0 fc 01 fb 71 fb 00 00 00 00 00 00 00 00 > 30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 07 00 > > 0000:01:00.3 PIC: Intel Corp. PCI Bridge Hub I/OxAPIC Interrupt Controller B > (rev 09) (prog-if 20 [IO(X)-APIC]) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0 > Region 0: Memory at fccff000 (32-bit, non-prefetchable) [size=4K] > Capabilities: [44] #10 [0001] > Capabilities: [6c] Power Management version 2 > Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 00: 86 80 27 03 46 01 10 00 09 20 00 08 00 00 80 00 > 10: 00 f0 cf fc 00 00 00 00 00 00 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 44 00 00 00 00 00 00 00 00 00 00 00 > > 0000:02:02.0 RAID bus controller: 3ware Inc 3ware ATA-RAID > Subsystem: 3ware Inc 3ware ATA-RAID > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (2250ns min), Cache Line Size: 0x10 (64 bytes) > Interrupt: pin A routed to IRQ 17 > Region 0: I/O ports at bc00 [size=256] > Region 1: Memory at fcdffc00 (64-bit, non-prefetchable) [size=256] > Region 3: Memory at fa800000 (64-bit, prefetchable) [size=8M] > Expansion ROM at fcde0000 [disabled] [size=64K] > Capabilities: [48] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA > PME(D0+,D1+,D2-,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 00: c1 13 02 10 5f 01 30 02 00 00 04 01 10 20 00 00 > 10: 01 bc 00 00 04 fc df fc 00 00 00 00 0c 00 80 fa > 20: 00 00 00 00 00 00 00 00 00 00 00 00 c1 13 02 10 > 30: 00 00 de fc 48 00 00 00 00 00 00 00 0a 01 09 00 > > 0000:02:03.0 RAID bus controller: 3ware Inc 3ware ATA-RAID > Subsystem: 3ware Inc 3ware ATA-RAID > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (2250ns min), Cache Line Size: 0x10 (64 bytes) > Interrupt: pin A routed to IRQ 18 > Region 0: I/O ports at b800 [size=256] > Region 1: Memory at fcdff800 (64-bit, non-prefetchable) [size=256] > Region 3: Memory at fa000000 (64-bit, prefetchable) [size=8M] > Expansion ROM at fcdd0000 [disabled] [size=64K] > Capabilities: [40] PCI-X non-bridge device. > Command: DPERE- ERO- RBC=0 OST=0 > Status: Bus=255 Dev=31 Func=0 64bit+ 133MHz+ SCD- USC-, > DC=simple, DMMRBC=0, DMOST=0, DMCRS=0, RSCEM- > Capabilities: [48] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA > PME(D0+,D1+,D2-,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 00: c1 13 02 10 5f 01 30 02 00 00 04 01 10 20 00 00 > 10: 01 b8 00 00 04 f8 df fc 00 00 00 00 0c 00 00 fa > 20: 00 00 00 00 00 00 00 00 00 00 00 00 c1 13 02 10 > 30: 00 00 dd fc 40 00 00 00 00 00 00 00 0a 01 09 00 > > 0000:03:01.0 RAID bus controller: 3ware Inc 3ware ATA-RAID > Subsystem: 3ware Inc 3ware ATA-RAID > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (2250ns min), Cache Line Size: 0x10 (64 bytes) > Interrupt: pin A routed to IRQ 19 > Region 0: I/O ports at cc00 [size=256] > Region 1: Memory at fceffc00 (64-bit, non-prefetchable) [size=256] > Region 3: Memory at fb000000 (64-bit, prefetchable) [size=8M] > Expansion ROM at fcee0000 [disabled] [size=64K] > Capabilities: [48] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA > PME(D0+,D1+,D2-,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 00: c1 13 02 10 5f 01 30 02 00 00 04 01 10 20 00 00 > 10: 01 cc 00 00 04 fc ef fc 00 00 00 00 0c 00 00 fb > 20: 00 00 00 00 00 00 00 00 00 00 00 00 c1 13 02 10 > 30: 00 00 ee fc 48 00 00 00 00 00 00 00 0a 01 09 00 > > 0000:05:00.0 Ethernet controller: Marvell Technology Group Ltd.: Unknown > device 4361 (rev 18) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 0x10 (64 bytes) > Interrupt: pin A routed to IRQ 223 > Region 0: Memory at fcffc000 (64-bit, non-prefetchable) [size=16K] > Region 2: I/O ports at dc00 [size=256] > Expansion ROM at fcfc0000 [disabled] [size=128K] > Capabilities: [48] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0+,D1+,D2+,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=1 PME- > Capabilities: [50] Vital Product Data > Capabilities: [5c] Message Signalled Interrupts: 64bit+ Queue=0/1 > Enable+ > Address: 00000000fee0f00c Data: 41e1 > Capabilities: [e0] #10 [0011] > 00: ab 11 61 43 47 05 10 00 18 00 00 02 10 00 00 00 > 10: 04 c0 ff fc 00 00 00 00 01 dc 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 fc fc 48 00 00 00 00 00 00 00 0a 01 00 00 > > 0000:07:04.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet > Controller (rev 05) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (63750ns min), Cache Line Size: 0x10 (64 bytes) > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at febe0000 (32-bit, non-prefetchable) [size=128K] > Region 2: I/O ports at ec80 [size=64] > Capabilities: [dc] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0+,D1-,D2-,D3hot+,D3cold+) > Status: D0 PME-Enable- DSel=0 DScale=1 PME- > Capabilities: [e4] PCI-X non-bridge device. > Command: DPERE- ERO+ RBC=0 OST=0 > Status: Bus=0 Dev=0 Func=0 64bit- 133MHz- SCD- USC-, > DC=simple, DMMRBC=2, DMOST=0, DMCRS=0, RSCEM- > 00: 86 80 76 10 57 01 30 02 05 00 00 02 10 20 00 00 > 10: 00 00 be fe 00 00 00 00 81 ec 00 00 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 00 00 dc 00 00 00 00 00 00 00 0a 01 ff 00 > > 0000:07:06.0 RAID bus controller: 3ware Inc 3ware ATA-RAID > Subsystem: 3ware Inc 3ware ATA-RAID > Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr+ > Stepping- SERR+ FastB2B- > Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (2250ns min), Cache Line Size: 0x10 (64 bytes) > Interrupt: pin A routed to IRQ 20 > Region 0: I/O ports at e800 [size=256] > Region 1: Memory at febdbc00 (64-bit, non-prefetchable) [size=256] > Region 3: Memory at fb800000 (64-bit, prefetchable) [size=8M] > Expansion ROM at fe020000 [disabled] [size=64K] > Capabilities: [48] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0+,D1+,D2+,D3hot+,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 00: c1 13 02 10 5f 01 30 02 00 00 04 01 10 20 00 00 > 10: 01 e8 00 00 04 bc bd fe 00 00 00 00 0c 00 80 fb > 20: 00 00 00 00 00 00 00 00 00 00 00 00 c1 13 02 10 > 30: 00 00 bc fe 48 00 00 00 00 00 00 00 0f 01 09 00 > > 0000:07:0c.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) > (prog-if 00 [VGA]) > Subsystem: Intel Corp.: Unknown device 3439 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- > Stepping+ SERR- FastB2B- > Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- > SERR- Latency: 32 (2000ns min), Cache Line Size: 0x10 (64 bytes) > Interrupt: pin A routed to IRQ 11 > Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M] > Region 1: I/O ports at e400 [size=256] > Region 2: Memory at febda000 (32-bit, non-prefetchable) [size=4K] > Expansion ROM at fe000000 [disabled] [size=128K] > Capabilities: [5c] Power Management version 2 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 PME-Enable- DSel=0 DScale=0 PME- > 00: 02 10 52 47 87 00 90 02 27 00 00 03 10 20 00 00 > 10: 00 00 00 fd 01 e4 00 00 00 a0 bd fe 00 00 00 00 > 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 39 34 > 30: 00 00 ba fe 5c 00 00 00 00 00 00 00 0b 01 08 00 > > # cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 15 > model : 4 > model name : Intel(R) Xeon(TM) CPU 3.20GHz > stepping : 10 > cpu MHz : 3192.358 > cache size : 2048 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 1 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm > constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm > bogomips : 6388.75 > > processor : 1 > vendor_id : GenuineIntel > cpu family : 15 > model : 4 > model name : Intel(R) Xeon(TM) CPU 3.20GHz > stepping : 10 > cpu MHz : 3192.358 > cache size : 2048 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 1 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm > constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm > bogomips : 6384.53 > > processor : 2 > vendor_id : GenuineIntel > cpu family : 15 > model : 4 > model name : Intel(R) Xeon(TM) CPU 3.20GHz > stepping : 10 > cpu MHz : 3192.358 > cache size : 2048 KB > physical id : 3 > siblings : 2 > core id : 0 > cpu cores : 1 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm > constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm > bogomips : 6384.50 > > processor : 3 > vendor_id : GenuineIntel > cpu family : 15 > model : 4 > model name : Intel(R) Xeon(TM) CPU 3.20GHz > stepping : 10 > cpu MHz : 3192.358 > cache size : 2048 KB > physical id : 3 > siblings : 2 > core id : 0 > cpu cores : 1 > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 5 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm > constant_tsc pni monitor ds_cpl cid cx16 xtpr lahf_lm > bogomips : 6384.54 > > # cat /proc/interrupts > CPU0 CPU1 CPU2 CPU3 > 0: 17246519 2140 2140 2148 IO-APIC-edge timer > 1: 3 3 2 2 IO-APIC-edge i8042 > 8: 3 0 1 0 IO-APIC-edge rtc > 9: 0 0 0 0 IO-APIC-fasteoi acpi > 12: 0 1 0 2 IO-APIC-edge i8042 > 14: 0 0 0 0 IO-APIC-edge libata > 15: 0 0 0 0 IO-APIC-edge libata > 16: 31000929 7811302 39894575 15870447 IO-APIC-fasteoi eth0 > 17: 1078416 3044826 2489404 1780707 IO-APIC-fasteoi 3w-9xxx > 18: 7107793 931865 5531801 862511 IO-APIC-fasteoi 3w-9xxx > 19: 494962 141885 25640 282908 IO-APIC-fasteoi 3w-9xxx > 20: 2130674 3511229 1293435 2256288 IO-APIC-fasteoi 3w-9xxx, > libata > 21: 0 0 0 0 IO-APIC-fasteoi > ehci_hcd:usb1 > 223: 0 0 0 1 PCI-MSI-edge eth1 > NMI: 17252842 17252814 17252813 17252812 > LOC: 17234121 17234121 17231585 17231584 > ERR: 0 > MIS: 0 > > # cat /proc/scsi/scsi > Attached devices: > Host: scsi0 Channel: 00 Id: 00 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi0 Channel: 00 Id: 01 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi0 Channel: 00 Id: 02 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi0 Channel: 00 Id: 03 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi0 Channel: 00 Id: 04 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi1 Channel: 00 Id: 00 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi1 Channel: 00 Id: 01 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi1 Channel: 00 Id: 02 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi1 Channel: 00 Id: 03 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi1 Channel: 00 Id: 04 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi1 Channel: 00 Id: 05 Lun: 00 > Vendor: AMCC Model: 9500S-12MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi2 Channel: 00 Id: 00 Lun: 00 > Vendor: AMCC Model: 9500S-8MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi3 Channel: 00 Id: 00 Lun: 00 > Vendor: AMCC Model: 9500S-8MI DISK Rev: 2.08 > Type: Direct-Access ANSI SCSI revision: 03 > Host: scsi6 Channel: 00 Id: 00 Lun: 00 > Vendor: ATA Model: ST3200822AS Rev: 3.01 > Type: Direct-Access ANSI SCSI revision: 05 > Host: scsi7 Channel: 00 Id: 00 Lun: 00 > Vendor: ATA Model: ST3200822AS Rev: 3.01 > Type: Direct-Access ANSI SCSI revision: 05 > > > > Any advice on how to go about fixing this would be appreciated. > > > > Kind regards, > > Jesper Juhl > > > PS. Please keep me on Cc: when replying. > > > > -- David Chatterton XFS Engineering Manager SGI Australia From owner-xfs@oss.sgi.com Fri Dec 22 05:50:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 05:50:58 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMDopqw006709 for ; Fri, 22 Dec 2006 05:50:53 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1GxkLG-0006Lg-9p; Fri, 22 Dec 2006 13:21:42 +0000 Date: Fri, 22 Dec 2006 13:21:42 +0000 From: Christoph Hellwig To: Nathan Scott Cc: David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Clear unwritten flag on during partial page truncation Message-ID: <20061222132142.GA23416@infradead.org> References: <20061220062813.GU44411608@melbourne.sgi.com> <1166681818.5572.190.camel@edge> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1166681818.5572.190.camel@edge> User-Agent: Mutt/1.4.2.2i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 10098 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs Content-Length: 1628 Lines: 34 On Thu, Dec 21, 2006 at 05:16:58PM +1100, Nathan Scott wrote: > On Wed, 2006-12-20 at 17:28 +1100, David Chinner wrote: > > Hence the solution is to clear the private buffer flags in > > xfs_vm_invalidatepage() so that when we extend the file the buffers > > on the page are all consistent. > > > > Patch below. Comments? > > Looks good Dave, nice sleuthing. > > In hindsight, it'd have been really good to have gone for the real > BH_Unwritten flag upfront, and then being able to clear that inside > discard_buffer (like was done for BH_Delay)... if we did that, then > all this new code we're adding here (to just clear_buffer_unwritten, > ultimately) and also the complete hack in xfs_count_page_state could > be removed. It still might be worth considering doing that, in case > there's other hard-to-hit-but-not-yet-uncovered bugs lurking along > the same lines. But alot of effort, with the possibility of it not > being merged at all, as it touches code outside XFS. D'oh. Getting code into buffer.c to fix this properly should be no problem at all. As usual we prefer to fix core code instead of working around it. This would also fix the data loss issue after we write through mmap into an unwritten extent. > > FWIW, GFS seems to have managed to do even worse here, and looks like > they have dup'd big chunks of buffer.c ... has a discard_buffer() copy > and invalidate_page and probably others which are closely derived from > the equivalent buffer.c code ... guess those guys (hi Russell) could > do some code rationalisation in this area too before they get bitten. GFS has crap code, news at 11 ;-) From owner-xfs@oss.sgi.com Fri Dec 22 08:19:14 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 08:19:17 -0800 (PST) Received: from MAIL-NY.norwalk.medtechinc.com (mail-ny.norwalk.medtechinc.com [216.169.14.95]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMGJCqw028410 for ; Fri, 22 Dec 2006 08:19:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Subject: XFS Date: Fri, 22 Dec 2006 11:06:07 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS Thread-Index: Accl4xa89pCQLwJLTFWuMpgLKCcPsQ== From: "Jaideep Nandy" To: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 10101 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jnandy@pbh-inc.com Precedence: bulk X-list: xfs Content-Length: 121 Lines: 12 How do I read a us drive that is XFS formatted using windows xp? Regards' JD [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Fri Dec 22 08:40:17 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 08:40:24 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMGeFqw030749 for ; Fri, 22 Dec 2006 08:40:17 -0800 Received: from [10.3.4.125] ([10.3.4.125]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006122211313847:1714 ; Fri, 22 Dec 2006 11:31:38 -0500 Message-ID: <458C0A38.3020105@falconstor.com> Date: Fri, 22 Dec 2006 11:39:20 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: xfs@oss.sgi.com Subject: Re: XFS References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/22/2006 11:31:38 AM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/22/2006 11:40:19 AM, Serialize complete at 12/22/2006 11:40:19 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 10102 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 238 Lines: 13 Jaideep Nandy wrote: > How do I read a us drive that is XFS formatted using windows xp? What is a us drive, and how did you make it XFS formatted using Windows XP? > [[HTML alternate version deleted]] Thanks! -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Fri Dec 22 09:43:47 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 09:43:50 -0800 (PST) Received: from evaldomino.Falconstor.com (mail1.falconstor.com [216.223.47.230]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMHhkqw005503 for ; Fri, 22 Dec 2006 09:43:47 -0800 Received: from [10.3.4.125] ([10.3.4.125]) by falconstormail.falconstor.net (Lotus Domino Release 5.0.11) with ESMTP id 2006122212350424:1735 ; Fri, 22 Dec 2006 12:35:04 -0500 Message-ID: <458C1917.4040807@falconstor.com> Date: Fri, 22 Dec 2006 12:42:47 -0500 From: "Geir A. Myrestrand" Reply-To: geir.myrestrand@falconstor.com Organization: FalconStor Software, Inc. User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jaideep Nandy , xfs@oss.sgi.com Subject: Re: XFS References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on FalconstorMail/FalconStor(Release 5.0.11 |July 24, 2002) at 12/22/2006 12:35:04 PM, Serialize by Router on evaldomino/FalconStor(Release 5.0.11 |July 24, 2002) at 12/22/2006 12:43:49 PM, Serialize complete at 12/22/2006 12:43:49 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-archive-position: 10104 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: geir.myrestrand@falconstor.com Precedence: bulk X-list: xfs Content-Length: 2079 Lines: 49 Jaideep Nandy wrote: > Usb drive. I used a tera station to format it with XFS and backed up > file onto it. > Now I want to use the drive on a regular win xp box with ntfs partition. Windows [XP] have no knowledge of XFS, nor have I ever heard of any applications running natively on Windows [XP] that can read XFS file systems. Your best bet is to use a Linux distro to read it. You can make your PC multi-boot, so that you either start up in Windows XP or in Linux/UNIX. You can also use a program like VMware Workstation or VMware Player (both are free) to install Linux in a virtual machine under Windows --then you can run both at the same time. If you do not want to install anything, then get a Linux live distro and boot from that. A live distro is a special DVD (or CD) that will let you run the OS directly from the optical disc, with no need to install anything on the local disk. You may need a USB drive or something like that to save configuration files, etc. Not all Linux distributions support XFS, but any version of SUSE Linux should serve the purpose. OpenSUSE 10.2 was just released and should do the job --see http://www.opensuse.org. Once you get access to the XFS file system from Linux on your PC, then you can copy it to a FAT partition, because both Windows and Linux support that. Or you can access your NTFS partition from Linux (if you dare) --see http://www.linux-ntfs.org. I'm assuming that the USB drive is independent of the Tera Station, if not then you can simply utilize the NAS feature of the Tera Station and map to the share from Windows XP. Also, if you do not have the Tera Station but have a Linux computer, then you could use Samba (see http://www.samba.org) to share out the USB disk and you could map to it from your Windows XP box. With a closed source OS it isn't trivial for anyone to provide you with direct support for a third party file system, it will be merely workarounds for deficiencies in the OS. I recommend you ditch your OS but keep your USB disk with XFS. ;-) -- Geir A. Myrestrand From owner-xfs@oss.sgi.com Fri Dec 22 10:31:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 10:31:19 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMIVBqw010191 for ; Fri, 22 Dec 2006 10:31:13 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.13.7/8.13.7/cfunix Mast-Sol 1.0) with ESMTP id kBMHgx8x000419 for ; Fri, 22 Dec 2006 12:42:59 -0500 (EST) Date: Fri, 22 Dec 2006 12:42:59 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: unexpected XFS SB magic number Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10105 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: xfs Content-Length: 1846 Lines: 56 Dear all, I have a 12 x 500Gb RAID-5 hardware RAID array on an ARECA 1130-ML controller. There is one single partition on it, exported as /dev/sdc1. This configuration used to work fine for 4 months. Then the computer crashed a couple of times, and led to a situation where xfs_check /dev/sdc1 output is: xfs_check: unexpected XFS SB magic number 0x45464920 xfs_check: size check failed xfs_check: read failed: Invalid argument xfs_check: data size check failed xfs_check: failed to alloc 58876353264 bytes: Cannot allocate memory I also checked the RAID, and seemingly the controller is fine; I can communicate with it, all 12 disks are visible, their SMART status is OK, the RAID-5 is reported to be in 'normal' condition, etc. [root@localhost ~]# xfs_db -r /dev/sdc1 xfs_db: unexpected XFS SB magic number 0x45464920 xfs_db: size check failed xfs_db: read failed: Invalid argument xfs_db: data size check failed xfs_db: failed to alloc 58876353264 bytes: Cannot allocate memory -------------------- [root@localhost ~]# xfs_repair -nv /dev/sdc1 Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... ................................................................................ ... ....................found candidate secondary superblock... unable to verify superblock, continuing... ... ....................found candidate secondary superblock... verified secondary superblock... would write modified primary superblock Primary superblock would have been modified. Cannot proceed further in no_modify mode. Exiting now. ---------------- I would very much appreciate advice on how to proceed in such situation. I worry that xfs_repair will repair, but may leave a mess that is hard to recover. I am hoping there may be a safer way. Best regards Gaspar From owner-xfs@oss.sgi.com Fri Dec 22 10:38:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 10:38:43 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMIccqw011471 for ; Fri, 22 Dec 2006 10:38:38 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.13.7/8.13.7/cfunix Mast-Sol 1.0) with ESMTP id kBMHjjov001070 for ; Fri, 22 Dec 2006 12:45:45 -0500 (EST) Date: Fri, 22 Dec 2006 12:45:44 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: unexpected XFS SB magic number Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10106 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: xfs Content-Length: 178 Lines: 10 Dear all, I forgot to mention some crucial information ( RE: unexpected XFS SB magic number. ) This is an AMD64 bit SMP system with 2.6.17-6 kernel under FC5. Cheers, Gaspar From owner-xfs@oss.sgi.com Fri Dec 22 12:40:01 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 12:40:06 -0800 (PST) Received: from slurp.thebarn.com (cattelan-host202.dsl.visi.com [208.42.117.202]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMKdwqw029414 for ; Fri, 22 Dec 2006 12:40:00 -0800 Received: from [127.0.0.1] (lupo.thebarn.com [10.0.0.10]) (authenticated bits=0) by slurp.thebarn.com (8.13.8/8.13.8) with ESMTP id kBMKC4K1054558; Fri, 22 Dec 2006 14:12:10 -0600 (CST) (envelope-from cattelan@thebarn.com) Subject: Re: unexpected XFS SB magic number From: Russell Cattelan To: gbakos@cfa.harvard.edu Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-S/44nacjDr44cG78WNeG" Date: Fri, 22 Dec 2006 14:12:04 -0600 Message-Id: <1166818324.20632.35.camel@xenon.msp.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1-1mdv2007.1 X-archive-position: 10107 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cattelan@thebarn.com Precedence: bulk X-list: xfs Content-Length: 2655 Lines: 88 --=-S/44nacjDr44cG78WNeG Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2006-12-22 at 12:42 -0500, Gaspar Bakos wrote: > Dear all, >=20 > I have a 12 x 500Gb RAID-5 hardware RAID array on an ARECA 1130-ML > controller. There is one single partition on it, exported as /dev/sdc1. > This configuration used to work fine for 4 months. > Then the computer crashed a couple of times, and led to a situation where >=20 > xfs_check /dev/sdc1 output is: >=20 > xfs_check: unexpected XFS SB magic number 0x45464920 > xfs_check: size check failed > xfs_check: read failed: Invalid argument > xfs_check: data size check failed > xfs_check: failed to alloc 58876353264 bytes: Cannot allocate memory What does=20 xfs_db /dev/sdc1 sb 0 p=20 look like? That will print out the contents of the superblock >=20 > I also checked the RAID, and seemingly the controller is fine; I can > communicate with it, all 12 disks are visible, their SMART status is > OK, the RAID-5 is reported to be in 'normal' condition, etc. >=20 > [root@localhost ~]# xfs_db -r /dev/sdc1 > xfs_db: unexpected XFS SB magic number 0x45464920 > xfs_db: size check failed > xfs_db: read failed: Invalid argument > xfs_db: data size check failed > xfs_db: failed to alloc 58876353264 bytes: Cannot allocate memory >=20 > -------------------- >=20 > [root@localhost ~]# xfs_repair -nv /dev/sdc1 >=20 > Phase 1 - find and verify superblock... > bad primary superblock - bad magic number !!! > attempting to find secondary superblock... > .........................................................................= ....... > ... > ....................found candidate secondary superblock... > unable to verify superblock, continuing... > ... > ....................found candidate secondary superblock... > verified secondary superblock... > would write modified primary superblock > Primary superblock would have been modified. > Cannot proceed further in no_modify mode. > Exiting now. >=20 > ---------------- >=20 >=20 > I would very much appreciate advice on how to proceed in such situation. > I worry that xfs_repair will repair, but may leave a mess that is hard > to recover. I am hoping there may be a safer way. >=20 >=20 > Best regards > Gaspar >=20 --=20 Russell Cattelan --=-S/44nacjDr44cG78WNeG Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFjDwUNRmM+OaGhBgRAg1RAJ96GG3Omlf8Rjprjeoi4hnx/AoolgCffxmq iSwLuVzDXVrwr85LGEjqqgg= =lSXr -----END PGP SIGNATURE----- --=-S/44nacjDr44cG78WNeG-- From owner-xfs@oss.sgi.com Fri Dec 22 12:52:57 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 12:53:02 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMKquqw031719 for ; Fri, 22 Dec 2006 12:52:57 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.13.7/8.13.7/cfunix Mast-Sol 1.0) with ESMTP id kBMKpFi4006476; Fri, 22 Dec 2006 15:51:15 -0500 (EST) Date: Fri, 22 Dec 2006 15:51:08 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Russell Cattelan cc: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number In-Reply-To: <1166818324.20632.35.camel@xenon.msp.redhat.com> Message-ID: References: <1166818324.20632.35.camel@xenon.msp.redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10108 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: xfs Content-Length: 534 Lines: 29 Dear Russell, RE: > xfs_db /dev/sdc1 > sb 0 > p > look like? Unfortunately I can not enter interactive mode with xfs_db: [root@localhost ~]# xfs_db /dev/sdc1 xfs_db: unexpected XFS SB magic number 0x45464920 xfs_db: size check failed xfs_db: read failed: Invalid argument xfs_db: data size check failed xfs_db: failed to alloc 58876353264 bytes: Cannot allocate memory [root@localhost ~]# I also tried specifying the command on the cmdline: xfs_db -c "sb 0" -c p /dev/sdc1 But I get exactly the same message. Cheers, Gaspar From owner-xfs@oss.sgi.com Fri Dec 22 15:13:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 15:13:33 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMNDPqw014719 for ; Fri, 22 Dec 2006 15:13:28 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 7F4D918022DEC; Fri, 22 Dec 2006 17:12:33 -0600 (CST) Message-ID: <458C6663.1050904@sandeen.net> Date: Fri, 22 Dec 2006 17:12:35 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: geir.myrestrand@falconstor.com CC: Jaideep Nandy , xfs@oss.sgi.com Subject: Re: XFS References: <458C1917.4040807@falconstor.com> In-Reply-To: <458C1917.4040807@falconstor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10109 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 2226 Lines: 49 Geir A. Myrestrand wrote: > Jaideep Nandy wrote: >> Usb drive. I used a tera station to format it with XFS and backed up >> file onto it. Now I want to use the drive on a regular win xp box with >> ntfs partition. > > Windows [XP] have no knowledge of XFS, nor have I ever heard of any > applications running natively on Windows [XP] that can read XFS file > systems. Your best bet is to use a Linux distro to read it. you could also try http://www.crossmeta.com/crossmeta.html > You can make your PC multi-boot, so that you either start up in Windows > XP or in Linux/UNIX. > > You can also use a program like VMware Workstation or VMware Player > (both are free) to install Linux in a virtual machine under Windows > --then you can run both at the same time. > > If you do not want to install anything, then get a Linux live distro and > boot from that. A live distro is a special DVD (or CD) that will let you > run the OS directly from the optical disc, with no need to install > anything on the local disk. You may need a USB drive or something like > that to save configuration files, etc. > > Not all Linux distributions support XFS, but any version of SUSE Linux > should serve the purpose. OpenSUSE 10.2 was just released and should do > the job --see http://www.opensuse.org. > > Once you get access to the XFS file system from Linux on your PC, then > you can copy it to a FAT partition, because both Windows and Linux > support that. Or you can access your NTFS partition from Linux (if you > dare) --see http://www.linux-ntfs.org. > > I'm assuming that the USB drive is independent of the Tera Station, if > not then you can simply utilize the NAS feature of the Tera Station and > map to the share from Windows XP. Also, if you do not have the Tera > Station but have a Linux computer, then you could use Samba (see > http://www.samba.org) to share out the USB disk and you could map to it > from your Windows XP box. > > With a closed source OS it isn't trivial for anyone to provide you with > direct support for a third party file system, it will be merely > workarounds for deficiencies in the OS. > > I recommend you ditch your OS but keep your USB disk with XFS. ;-) > > From owner-xfs@oss.sgi.com Fri Dec 22 15:29:30 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 15:29:35 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMNTTqw016819 for ; Fri, 22 Dec 2006 15:29:30 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.13.7/8.13.7/cfunix Mast-Sol 1.0) with ESMTP id kBMNSclh004212; Fri, 22 Dec 2006 18:28:38 -0500 (EST) Date: Fri, 22 Dec 2006 18:28:38 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number In-Reply-To: <458C6719.6080106@sandeen.net> Message-ID: References: <458C6719.6080106@sandeen.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10110 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: xfs Content-Length: 738 Lines: 31 Hi, Eric, RE: > > xfs_check: unexpected XFS SB magic number 0x45464920 > That spells "EFI" Does this have any special meaning? E.g. I could figure out who labelled the disk (array)? > looks like somebody came along & labeled your disk for you. Dangers of > being on a san I suppose (if you are....) Humm. This is an FC5 with SMP opteron. The RAID-5 (12 disks) is ran by an ARECA 1130-ML card. > repair might fix it.... I worry that what repair will leave behind is pure numbers (and many of those), like 11212/ 12133/ 121212/ ... and to reconstruct ~3Tb from that is not trivial... This reminds me: what paranoid safety measures can one take? E.g keep an external log of the filesystem as well? Thanks for the thoughts! Gaspar From owner-xfs@oss.sgi.com Fri Dec 22 15:33:56 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 15:34:00 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMNXtqw017664 for ; Fri, 22 Dec 2006 15:33:56 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 44D4518E21509; Fri, 22 Dec 2006 17:33:04 -0600 (CST) Message-ID: <458C6B32.5090004@sandeen.net> Date: Fri, 22 Dec 2006 17:33:06 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number References: <458C6719.6080106@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10111 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 838 Lines: 35 Gaspar Bakos wrote: > Hi, Eric, > > RE: >>> xfs_check: unexpected XFS SB magic number 0x45464920 >> That spells "EFI" > > Does this have any special meaning? E.g. I could figure out who > labelled the disk (array)? EFI is a bootloader.... >> looks like somebody came along & labeled your disk for you. Dangers of >> being on a san I suppose (if you are....) > > Humm. This is an FC5 with SMP opteron. The RAID-5 (12 disks) is ran by > an ARECA 1130-ML card. > >> repair might fix it.... > > I worry that what repair will leave behind is pure numbers (and many of those), like > 11212/ > 12133/ > 121212/ > ... > and to reconstruct ~3Tb from that is not trivial... > > This reminds me: what paranoid safety measures can one take? E.g keep > an external log of the filesystem as well? > > Thanks for the thoughts! > > Gaspar > From owner-xfs@oss.sgi.com Fri Dec 22 15:37:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 15:37:26 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMNbKqw018357 for ; Fri, 22 Dec 2006 15:37:21 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4428518022DEC; Fri, 22 Dec 2006 17:15:35 -0600 (CST) Message-ID: <458C6719.6080106@sandeen.net> Date: Fri, 22 Dec 2006 17:15:37 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10112 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 569 Lines: 21 Gaspar Bakos wrote: > Dear all, > > I have a 12 x 500Gb RAID-5 hardware RAID array on an ARECA 1130-ML > controller. There is one single partition on it, exported as /dev/sdc1. > This configuration used to work fine for 4 months. > Then the computer crashed a couple of times, and led to a situation where > > xfs_check /dev/sdc1 output is: > > xfs_check: unexpected XFS SB magic number 0x45464920 That spells "EFI" looks like somebody came along & labeled your disk for you. Dangers of being on a san I suppose (if you are....) repair might fix it.... -Eric From owner-xfs@oss.sgi.com Fri Dec 22 15:38:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 15:38:57 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBMNcpqw018710 for ; Fri, 22 Dec 2006 15:38:53 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 5829518022DEC; Fri, 22 Dec 2006 17:38:00 -0600 (CST) Message-ID: <458C6C5A.6090504@sandeen.net> Date: Fri, 22 Dec 2006 17:38:02 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number References: <458C6719.6080106@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10113 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 760 Lines: 26 Gaspar Bakos wrote: > This reminds me: what paranoid safety measures can one take? E.g keep > an external log of the filesystem as well? it looks like you wound up with an efi bootloader splatted over the front of your partition. maybe the raid got scrambled around? Or maybe someone actually installed a bootloader over an otherwise-ok filesystem? hard to say. not sure what could have prevented either of those. are you sure the raid is in the right shape, and in the right order of disks? i also remember something about parted (maybe...) finding a backup gpt signature at the end of a disk, and "helpfully" copying it over the front end if so. This was a bug. sgi guys do you remember? -Eric > Thanks for the thoughts! > > Gaspar > From owner-xfs@oss.sgi.com Fri Dec 22 18:57:04 2006 Received: with ECARTIS (v1.0.0; list xfs); Fri, 22 Dec 2006 18:57:10 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBN2v0qw012773 for ; Fri, 22 Dec 2006 18:57:02 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA23865; Sat, 23 Dec 2006 13:56:04 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id kBN2u17Y70519867; Sat, 23 Dec 2006 13:56:01 +1100 (AEDT) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id kBN2twic71021347; Sat, 23 Dec 2006 13:55:58 +1100 (AEDT) Date: Sat, 23 Dec 2006 13:55:58 +1100 From: David Chinner To: Christoph Hellwig Cc: Nathan Scott , David Chinner , xfs-dev@sgi.com, xfs@oss.sgi.com Subject: Re: Review: Clear unwritten flag on during partial page truncation Message-ID: <20061223025558.GJ44411608@melbourne.sgi.com> References: <20061220062813.GU44411608@melbourne.sgi.com> <1166681818.5572.190.camel@edge> <20061222132142.GA23416@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061222132142.GA23416@infradead.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 10114 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: xfs Content-Length: 1486 Lines: 36 On Fri, Dec 22, 2006 at 01:21:42PM +0000, Christoph Hellwig wrote: > On Thu, Dec 21, 2006 at 05:16:58PM +1100, Nathan Scott wrote: > > On Wed, 2006-12-20 at 17:28 +1100, David Chinner wrote: > > > Hence the solution is to clear the private buffer flags in > > > xfs_vm_invalidatepage() so that when we extend the file the buffers > > > on the page are all consistent. > > > > > > Patch below. Comments? > > > > Looks good Dave, nice sleuthing. > > > > In hindsight, it'd have been really good to have gone for the real > > BH_Unwritten flag upfront, and then being able to clear that inside > > discard_buffer (like was done for BH_Delay)... if we did that, then > > all this new code we're adding here (to just clear_buffer_unwritten, > > ultimately) and also the complete hack in xfs_count_page_state could > > be removed. It still might be worth considering doing that, in case > > there's other hard-to-hit-but-not-yet-uncovered bugs lurking along > > the same lines. But alot of effort, with the possibility of it not > > being merged at all, as it touches code outside XFS. D'oh. > > Getting code into buffer.c to fix this properly should be no problem > at all. As usual we prefer to fix core code instead of working around > it. This would also fix the data loss issue after we write through mmap > into an unwritten extent. Ok, I'll work up a patch for it in the new year, Christoph. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group From owner-xfs@oss.sgi.com Sat Dec 23 07:36:13 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 23 Dec 2006 07:36:17 -0800 (PST) Received: from deflector.emaze.net (deflector.emaze.net [213.178.220.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBNFaCqw010754 for ; Sat, 23 Dec 2006 07:36:13 -0800 Received: from localhost (localhost [127.0.0.1]) by deflector.emaze.net (Postfix) with ESMTP id 8F6E7F2816D for ; Sat, 23 Dec 2006 16:15:12 +0100 (CET) Received: from deflector.emaze.net ([127.0.0.1]) by localhost (deflector [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06830-03 for ; Sat, 23 Dec 2006 16:15:12 +0100 (CET) Received: from [192.168.10.55] (host68-236-dynamic.5-87-r.retail.telecomitalia.it [87.5.236.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deflector.emaze.net (Postfix) with ESMTP id 459C2F28080 for ; Sat, 23 Dec 2006 16:15:12 +0100 (CET) Message-ID: <458D4845.2010803@emaze.net> Date: Sat, 23 Dec 2006 16:16:21 +0100 From: fdegrassi User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Possible performance problem introduced between kernel 2.6.15 and 2.6.17 on xfs code Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10115 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: francesco.degrassi@emaze.net Precedence: bulk X-list: xfs Content-Length: 560 Lines: 13 Hi all, i noticed that changing from kernel 2.6.15 to 2.6.17, gnomevfs-copy operations suffered an heavy performance hit (20 times slower). I checked quickly (i am not a kernel hacker) and i think it could be related to libgnomevfs calling fadvice POSIX_FADV_DONTNEED (in gnome_vfs_forget_cache, disabling this behaviour gets back normal performance). I am not able to dig deeper than this, anyway it could be a starting point. The relevant gnome bugzilla reference is the following: http://bugzilla.gnome.org/show_bug.cgi?id=363400 Francesco Degrassi From owner-xfs@oss.sgi.com Sat Dec 23 07:45:35 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 23 Dec 2006 07:45:38 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBNFjYqw012214 for ; Sat, 23 Dec 2006 07:45:35 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 957281801384A; Sat, 23 Dec 2006 09:44:42 -0600 (CST) Message-ID: <458D4EEB.3060501@sandeen.net> Date: Sat, 23 Dec 2006 09:44:43 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: fdegrassi CC: linux-xfs@oss.sgi.com Subject: Re: Possible performance problem introduced between kernel 2.6.15 and 2.6.17 on xfs code References: <458D4845.2010803@emaze.net> In-Reply-To: <458D4845.2010803@emaze.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10116 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 687 Lines: 20 fdegrassi wrote: > Hi all, > i noticed that changing from kernel 2.6.15 to 2.6.17, gnomevfs-copy > operations suffered an heavy performance hit (20 times slower). > I checked quickly (i am not a kernel hacker) and i think it could be > related to libgnomevfs calling fadvice POSIX_FADV_DONTNEED (in > gnome_vfs_forget_cache, disabling this behaviour gets back normal > performance). > I am not able to dig deeper than this, anyway it could be a starting point. > The relevant gnome bugzilla reference is the following: > http://bugzilla.gnome.org/show_bug.cgi?id=363400 > > Francesco Degrassi > > Is a copy command from the shell affected, or just gnome point-n-click? -Eric From owner-xfs@oss.sgi.com Sat Dec 23 15:09:54 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 23 Dec 2006 15:09:58 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBNN9qqw029292 for ; Sat, 23 Dec 2006 15:09:53 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.13.7/8.13.7/cfunix Mast-Sol 1.0) with ESMTP id kBNN8wp2007605; Sat, 23 Dec 2006 18:08:58 -0500 (EST) Date: Sat, 23 Dec 2006 18:08:58 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number In-Reply-To: <458C6C5A.6090504@sandeen.net> Message-ID: References: <458C6719.6080106@sandeen.net> <458C6C5A.6090504@sandeen.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10119 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: xfs Content-Length: 2162 Lines: 53 Hi, Eric, RE: > it looks like you wound up with an efi bootloader splatted over the > front of your partition. maybe the raid got scrambled around? Or maybe > someone actually installed a bootloader over an otherwise-ok filesystem? > hard to say. not sure what could have prevented either of those. To summarize; this is a hardware RAID-6 (and not a RAID-5 as I wrote earlier) of 12 x 500Gb disks, thus the size is 5Tb. The RAID card is an ARECA 1130-ML card. The computer runs FC5 with 2.6.17-6 (kernel.org) kernel. It was quite stable for 4 monhts. I remember originally there was a problem with partitioning. fdisk could not handle the 5Tb partition size (I needed one big partition, it was out of question to split it up). Then per recommendation of someone from another list, I used gparted and set the partition type to GPT. This indeed made the job, and I was able to create a 5Tb partition. mkfs.xfs worked fine (xfsprogs-2.7.3-1.2.1) I can definitely say that the RAID was not scrambled around. There are only few users on this computer, and only one superuser (myself) and no physical access to the computer by others. One of the users was running quite memory and disk IO intensive tasks past week. This lead to a crash. (I was not around to keep an eye on it). The computer rebooted, and few days later another crash, etc. Finally, when I returned this week, I found it powered off. And then I realized that the sdc1 partition can not be mounted any more. > i also remember something about parted (maybe...) finding a backup gpt > signature at the end of a disk, and "helpfully" copying it over the > front end if so. This was a bug. sgi guys do you remember? But for this one has to invoke parted, and commit the operations done, am I right? Maybe there is a nasty daemon doing something. The fs was also exported as NFS and mounted by two other hosts. --------- So the questions are: - what partition type to choose next time? - is there a simpler way of recovery (than xfs_recovery), i.e. the first few bytes of the partition need to be changed back to something XFS magic, and the rest is probably untouched? Cheers Gaspar From owner-xfs@oss.sgi.com Sat Dec 23 16:37:28 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 23 Dec 2006 16:37:32 -0800 (PST) Received: from deflector.emaze.net (deflector.emaze.net [213.178.220.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBO0bOqw011126 for ; Sat, 23 Dec 2006 16:37:27 -0800 Received: from localhost (localhost [127.0.0.1]) by deflector.emaze.net (Postfix) with ESMTP id B1957F2816D for ; Sun, 24 Dec 2006 01:35:17 +0100 (CET) Received: from deflector.emaze.net ([127.0.0.1]) by localhost (deflector [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09604-09 for ; Sun, 24 Dec 2006 01:35:17 +0100 (CET) Received: from [192.168.10.55] (host68-236-dynamic.5-87-r.retail.telecomitalia.it [87.5.236.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deflector.emaze.net (Postfix) with ESMTP id 3DDF6F28080 for ; Sun, 24 Dec 2006 01:35:17 +0100 (CET) Message-ID: <458DCB8D.3040804@emaze.net> Date: Sun, 24 Dec 2006 01:36:29 +0100 From: fdegrassi User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Possible performance problem introduced between kernel 2.6.15 and 2.6.17 on xfs code References: <458D4845.2010803@emaze.net> <458D4EEB.3060501@sandeen.net> In-Reply-To: <458D4EEB.3060501@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10124 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: francesco.degrassi@emaze.net Precedence: bulk X-list: xfs Content-Length: 1242 Lines: 35 The specific problem is related to gnome point-n-click only. Anyway, I could be wrong, but i don't think it is a bug in gnome because: 1. it affects specifically local XFS filesystems only 2. the problem is not present on kernel 2.6.15 (I tested 2.6.17 and 2.6.15, both on ubuntu 6.10) 3. the problem does not manifest if i disable the call to gnome_vfs_forget_cache, that, for what i understand, simply calls fadvice POSIX_FADV_DONTNEED. More info can be found on gnome bugzilla entry. Francesco Degrassi Eric Sandeen wrote: > fdegrassi wrote: >> Hi all, >> i noticed that changing from kernel 2.6.15 to 2.6.17, gnomevfs-copy >> operations suffered an heavy performance hit (20 times slower). >> I checked quickly (i am not a kernel hacker) and i think it could be >> related to libgnomevfs calling fadvice POSIX_FADV_DONTNEED (in >> gnome_vfs_forget_cache, disabling this behaviour gets back normal >> performance). >> I am not able to dig deeper than this, anyway it could be a starting >> point. >> The relevant gnome bugzilla reference is the following: >> http://bugzilla.gnome.org/show_bug.cgi?id=363400 >> >> Francesco Degrassi >> >> > > Is a copy command from the shell affected, or just gnome point-n-click? > > -Eric From owner-xfs@oss.sgi.com Sat Dec 23 20:06:23 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 23 Dec 2006 20:06:28 -0800 (PST) Received: from s-utl01-dcpop.stsn.net (s-utl01-dcpop.stsn.net [72.255.0.201]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBO46Lqx030511 for ; Sat, 23 Dec 2006 20:06:23 -0800 Received: from s-utl01-dcpop.stsn.net ([127.0.0.1]) by s-utl01-dcpop.stsn.net (SMSSMTP 4.1.2.20) with SMTP id M2006122322502230719 ; Sat, 23 Dec 2006 22:50:22 -0500 Received: from [10.26.7.119] ([10.26.7.119]) by s-utl01-dcpop.stsn.net; Sat, 23 Dec 2006 22:50:22 -0500 Message-ID: <458DF8F7.5030104@sandeen.net> Date: Sat, 23 Dec 2006 21:50:15 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: gbakos@cfa.harvard.edu CC: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number References: <458C6719.6080106@sandeen.net> <458C6C5A.6090504@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10127 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 1411 Lines: 38 Gaspar Bakos wrote: > Hi, Eric, > One of the users was running quite memory and disk IO intensive tasks > past week. This lead to a crash. (I was not around to keep an eye on > it). The computer rebooted, and few days later another crash, etc. > Finally, when I returned this week, I found it powered off. > > And then I realized that the sdc1 partition can not be mounted any more. Well, something put a gpt label on top of your xfs partition... and it wasn't xfs :) >> i also remember something about parted (maybe...) finding a backup gpt >> signature at the end of a disk, and "helpfully" copying it over the >> front end if so. This was a bug. sgi guys do you remember? > > But for this one has to invoke parted, and commit the operations done, > am I right? if I recall, even invoking parted could do this. > Maybe there is a nasty daemon doing something. The fs was also exported > as NFS and mounted by two other hosts. > > --------- > So the questions are: > - what partition type to choose next time? > - is there a simpler way of recovery (than xfs_recovery), i.e. the > first few bytes of the partition need to be changed back to something > XFS magic, and the rest is probably untouched? i'd google around and find out how big the gpt header is; try to find out how much of the front of your partition got clobbered. that'll give a clue as to how much you may have lost. -Eric From owner-xfs@oss.sgi.com Sat Dec 23 22:09:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Sat, 23 Dec 2006 22:09:49 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBO69gqw014284 for ; Sat, 23 Dec 2006 22:09:43 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.13.7/8.13.7/cfunix Mast-Sol 1.0) with ESMTP id kBO68jUU009487; Sun, 24 Dec 2006 01:08:45 -0500 (EST) Date: Sun, 24 Dec 2006 01:08:44 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number In-Reply-To: <458DF8F7.5030104@sandeen.net> Message-ID: References: <458C6719.6080106@sandeen.net> <458C6C5A.6090504@sandeen.net> <458DF8F7.5030104@sandeen.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10128 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gbakos@cfa.harvard.edu Precedence: bulk X-list: xfs Content-Length: 1356 Lines: 44 Hi, Eric, RE: > Well, something put a gpt label on top of your xfs partition... and it > wasn't xfs :) After some contemplation I allowed xfs_repair to make an attempt. It seems that nothing was recovered. If found a secondary suplerblock, and then lot of message followed ... (attached). The repaired XFS filesystem is 2Tb in size (as opposed to the 5TB), and 0% is used: Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdd1 2147352448 528 2147351920 1% /mnt/ar1/un0 After the recovery parted reports: Error: Unable to open /dev/sdd - unrecognised disk label. ( For parted /dev/sdd1: partition type reported as 'loop'. _ fdisk reports GPT partition type for /dev/sdd: [root@cfhat7 xfs]# fdisk -l /dev/sdd WARNING: GPT (GUID Partition Table) detected on '/dev/sdd'! The util fdisk doesn't support GPT. Use GNU Parted. Disk /dev/sdd: 4999.9 GB, 4999998341120 bytes 255 heads, 63 sectors/track, 607881 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sdd1 1 267350 2147483647+ ee EFI GPT --------- So all this is a great mess. parted is supposed to be better than fdisk, yet it does not recognize what fdisk does? Now having lost all the data, I may start experimenting if I can reproduce this. Gaspar From owner-xfs@oss.sgi.com Sun Dec 24 04:01:15 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 24 Dec 2006 04:01:21 -0800 (PST) Received: from taiwan.yingternet.net (taiwan.yingternet.net [59.124.122.220]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBOC1Dqw020404 for ; Sun, 24 Dec 2006 04:01:14 -0800 Message-ID: <458E643D.3090008@yingternet.com> Date: Sun, 24 Dec 2006 19:27:57 +0800 From: Ying-Hung Chen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: xfs_repair xfsprogs version > 2.8.11 X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10129 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: xfs Content-Length: 435 Lines: 19 Hi there, I found that xfs_repair always returns the following message with the xfsprogs version > 2.8.11 [root@yroro i586]# xfs_repair /dev/hdb1 fatal error -- status from pthread_attr_setstacksize: 22 from the ChangeLog, seems like there is some internal changes with threads starting 2.8.11 .. the xfs_repair works for me up to 2.8.11, it fails to work on 2.8.16 and 2.8.18, how do I work around this problem? Thanks, -Ying From owner-xfs@oss.sgi.com Sun Dec 24 04:40:09 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 24 Dec 2006 04:40:14 -0800 (PST) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBOCe8qw029652 for ; Sun, 24 Dec 2006 04:40:09 -0800 Received: from teal.hq.k1024.org (84-75-114-110.dclient.hispeed.ch [84.75.114.110]) by astra.simleu.ro (Postfix) with ESMTP id EAD775B; Sun, 24 Dec 2006 14:16:33 +0200 (EET) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 1C0F340A55C; Sun, 24 Dec 2006 13:16:23 +0100 (CET) Date: Sun, 24 Dec 2006 13:16:22 +0100 From: Iustin Pop To: Gaspar Bakos Cc: linux-xfs@oss.sgi.com Subject: Re: unexpected XFS SB magic number Message-ID: <20061224121622.GA22721@teal.hq.k1024.org> Mail-Followup-To: Gaspar Bakos , linux-xfs@oss.sgi.com References: <458C6719.6080106@sandeen.net> <458C6C5A.6090504@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 10130 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs Content-Length: 332 Lines: 13 On Sat, Dec 23, 2006 at 06:08:58PM -0500, Gaspar Bakos wrote: > So the questions are: > - what partition type to choose next time? In cases where I want to use the whole disk, I usually make the filesystem directly over the disk (e.g. /dev/sdc) instead of partitioning it. Never had any problem with this setup. Regards, Iustin From owner-xfs@oss.sgi.com Mon Dec 25 02:00:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Mon, 25 Dec 2006 02:00:28 -0800 (PST) Received: from taiwan.yingternet.net (taiwan.yingternet.net [59.124.122.220]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBPA0Iqw008793 for ; Mon, 25 Dec 2006 02:00:21 -0800 Message-ID: <458FA0F8.1020107@yingternet.com> Date: Mon, 25 Dec 2006 17:59:20 +0800 From: Ying-Hung Chen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: linux-xfs@oss.sgi.com CC: Ying-Hung Chen Subject: Re: xfs_repair xfsprogs version > 2.8.11 References: <458E643D.3090008@yingternet.com> In-Reply-To: <458E643D.3090008@yingternet.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10131 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: xfs Content-Length: 1374 Lines: 56 Hi there, actually, i have trace the code in to xfs_repair/threads.c (taken from 2.8.18) void thread_init(void) { .... if ((status = pthread_attr_getstacksize(&attr, &stacksize)) != 0) do_error(_("status from pthread_attr_getstacksize: %d"), status); stacksize *= 4; if ((status = pthread_attr_setstacksize(&attr, stacksize)) != 0) do_error(_("status from pthread_attr_setstacksize: %d"), status); .... } the repair program dies in pthread_attr_setstacksize(&attr, stacksize)). is there any reason why the program is trying to set the stacksize into 4 times the current size? just for testing purposes, I remove the stacksize *= 4; the xfs_repair seems to 'work', at least from user's point of view. I have tested with x86 32bits machines with 2.4 and 2.6 kernels, they both yield with the same results, Thanks, -Ying Ying-Hung Chen wrote: > Hi there, > > I found that xfs_repair always returns the following message with the > xfsprogs version > 2.8.11 > > [root@yroro i586]# xfs_repair /dev/hdb1 > > fatal error -- status from pthread_attr_setstacksize: 22 > > from the ChangeLog, seems like there is some internal changes with > threads starting 2.8.11 .. the xfs_repair works for me up to 2.8.11, it > fails to work on 2.8.16 and 2.8.18, > > how do I work around this problem? > > Thanks, > > -Ying > From owner-xfs@oss.sgi.com Tue Dec 26 13:27:42 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 26 Dec 2006 13:27:47 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBQLRUqw007374 for ; Tue, 26 Dec 2006 13:27:32 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id 12A54616D16C; Tue, 26 Dec 2006 16:26:39 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 101BA16134E33; Tue, 26 Dec 2006 16:26:39 -0500 (EST) Date: Tue, 26 Dec 2006 16:26:39 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: linux-kernel@vger.kernel.org cc: xfs@oss.sgi.com Subject: Kernel 2.6.19: Kernel Panic! XFS / UDEV Issue? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10137 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 74435 Lines: 1710 I use netconsole on all my machines and it caught the crash, I was not doing anything special, just rebooted my machine and when it was booting, this happened: Looks like an XFS problem? System Events =-=-=-=-=-=-= Dec 26 15:59:37 box [ 0.000000] BIOS-provided physical RAM map: Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 0000000000100000 - 000000007fff0000 (usable) Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 000000007fff0000 - 000000007fff3000 (ACPI NVS) Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data) Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) Dec 26 15:59:37 box [ 0.000000] 1151MB HIGHMEM available. Dec 26 15:59:37 box [ 0.000000] 896MB LOWMEM available. Dec 26 15:59:37 box [ 0.000000] found SMP MP-table at 000f5d10 Dec 26 15:59:37 box [ 0.000000] Zone PFN ranges: Dec 26 15:59:37 box [ 0.000000] DMA 0 -> 4096 Dec 26 15:59:37 box [ 0.000000] Normal 4096 -> 229376 Dec 26 15:59:37 box [ 0.000000] HighMem 229376 -> 524272 Dec 26 15:59:37 box [ 0.000000] early_node_map[1] active PFN ranges Dec 26 15:59:37 box [ 0.000000] 0: 0 -> 524272 Dec 26 15:59:37 box [ 0.000000] DMI 2.2 present. Dec 26 15:59:37 box [ 0.000000] ACPI: PM-Timer IO Port: 0x408 Dec 26 15:59:37 box [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Dec 26 15:59:37 box [ 0.000000] Processor #0 15:2 APIC version 20 Dec 26 15:59:37 box [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Dec 26 15:59:37 box [ 0.000000] Processor #1 15:2 APIC version 20 Dec 26 15:59:37 box [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) Dec 26 15:59:37 box [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) Dec 26 15:59:37 box [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) Dec 26 15:59:37 box [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 Dec 26 15:59:37 box [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Dec 26 15:59:37 box [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Dec 26 15:59:37 box [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs Dec 26 15:59:37 box [ 0.000000] Using ACPI (MADT) for SMP configuration information Dec 26 15:59:37 box [ 0.000000] Allocating PCI resources starting at 88000000 (gap: 80000000:7ec00000) Dec 26 15:59:37 box [ 0.000000] Detected 2606.071 MHz processor. Dec 26 15:59:37 box [ 22.359952] Built 1 zonelists. Total pages: 520177 Dec 26 15:59:37 box [ 22.359955] Kernel command line: auto BOOT_IMAGE=2.6.19-2 ro root=802 netconsole=4444@192.168.168.1/eth0,514@192.168.0.254/00:07:C9:55:47:AB nmi_watchdog=1 Dec 26 15:59:37 box [ 22.359995] netconsole: local port 4444 Dec 26 15:59:37 box [ 22.359998] netconsole: local IP 192.168.168.1 Dec 26 15:59:37 box [ 22.360000] netconsole: interface eth0 Dec 26 15:59:37 box [ 22.360002] netconsole: remote port 514 Dec 26 15:59:37 box [ 22.360004] netconsole: remote IP 192.168.0.254 Dec 26 15:59:37 box [ 22.360008] netconsole: remote ethernet address 00:07:e9:29:37:db Dec 26 15:59:37 box [ 22.360179] Enabling fast FPU save and restore... done. Dec 26 15:59:37 box [ 22.360182] Enabling unmasked SIMD FPU exception support... done. Dec 26 15:59:37 box [ 22.360186] Initializing CPU#0 Dec 26 15:59:37 box [ 22.360251] PID hash table entries: 4096 (order: 12, 16384 bytes) Dec 26 15:59:37 box [ 22.361425] Console: colour VGA+ 80x25 Dec 26 15:59:37 box [ 22.364157] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Dec 26 15:59:37 box [ 22.364658] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Dec 26 15:59:37 box [ 22.463391] Memory: 2074188k/2097088k available (3017k kernel code, 21684k reserved, 872k data, 216k init, 1179584k highmem) Dec 26 15:59:37 box [ 22.463467] virtual kernel memory layout: Dec 26 15:59:37 box [ 22.463468] fixmap : 0xfff9d000 - 0xfffff000 ( 392 kB) Dec 26 15:59:37 box [ 22.463469] pkmap : 0xff800000 - 0xffc00000 (4096 kB) Dec 26 15:59:37 box [ 22.463470] vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) Dec 26 15:59:37 box [ 22.463471] lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) Dec 26 15:59:37 box [ 22.463472] .init : 0xc04d3000 - 0xc0509000 ( 216 kB) Dec 26 15:59:37 box [ 22.463473] .data : 0xc03f2412 - 0xc04cc424 ( 872 kB) Dec 26 15:59:37 box [ 22.463475] .text : 0xc0100000 - 0xc03f2412 (3017 kB) Dec 26 15:59:37 box [ 22.463860] Checking if this processor honours the WP bit even in supervisor mode... Ok. Dec 26 15:59:37 box [ 22.523834] Calibrating delay using timer specific routine.. 5213.93 BogoMIPS (lpj=2606966) Dec 26 15:59:37 box [ 22.523973] Mount-cache hash table entries: 512 Dec 26 15:59:37 box [ 22.524142] CPU: Trace cache: 12K uops, L1 D cache: 8K Dec 26 15:59:37 box [ 22.524226] CPU: L2 cache: 512K Dec 26 15:59:37 box [ 22.524274] CPU: Physical Processor ID: 0 Dec 26 15:59:37 box [ 22.524343] Checking 'hlt' instruction... OK. Dec 26 15:59:37 box [ 22.528015] Freeing SMP alternatives: 12k freed Dec 26 15:59:37 box [ 22.528065] ACPI: Core revision 20060707 Dec 26 15:59:37 box [ 22.547938] CPU0: Intel(R) Pentium(R) 4 CPU 2.60GHz stepping 09 Dec 26 15:59:37 box [ 22.548078] Booting processor 1/1 eip 2000 Dec 26 15:59:37 box [ 22.558416] Initializing CPU#1 Dec 26 15:59:37 box [ 22.618587] Calibrating delay using timer specific routine.. 5211.07 BogoMIPS (lpj=2605538) Dec 26 15:59:37 box [ 22.618607] CPU: Trace cache: 12K uops, L1 D cache: 8K Dec 26 15:59:37 box [ 22.618610] CPU: L2 cache: 512K Dec 26 15:59:37 box [ 22.618612] CPU: Physical Processor ID: 0 Dec 26 15:59:37 box [ 22.618778] CPU1: Intel(R) Pentium(R) 4 CPU 2.60GHz stepping 09 Dec 26 15:59:37 box [ 22.619156] Total of 2 processors activated (10425.00 BogoMIPS). Dec 26 15:59:37 box [ 22.619333] ENABLING IO-APIC IRQs Dec 26 15:59:37 box [ 22.619553] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 Dec 26 15:59:37 box [ 22.731308] checking TSC synchronization across 2 CPUs: passed. Dec 26 15:59:37 box [ 0.000955] Brought up 2 CPUs Dec 26 15:59:37 box [ 0.054654] migration_cost=44 Dec 26 15:59:37 box [ 0.055223] NET: Registered protocol family 16 Dec 26 15:59:37 box [ 0.055360] ACPI: bus type pci registered Dec 26 15:59:37 box [ 0.067272] PCI: PCI BIOS revision 2.10 entry at 0xfb720, last bus=3 Dec 26 15:59:37 box [ 0.067324] PCI: Using configuration type 1 Dec 26 15:59:37 box [ 0.067372] Setting up standard PCI resources Dec 26 15:59:37 box [ 0.078356] ACPI: Interpreter enabled Dec 26 15:59:37 box [ 0.078409] ACPI: Using IOAPIC for interrupt routing Dec 26 15:59:37 box [ 0.079073] ACPI: PCI Root Bridge [PCI0] (0000:00) Dec 26 15:59:37 box [ 0.081912] PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO Dec 26 15:59:37 box [ 0.081966] PCI quirk: region 0480-04bf claimed by ICH4 GPIO Dec 26 15:59:37 box [ 0.082062] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 Dec 26 15:59:37 box [ 0.082778] PCI: Transparent bridge - 0000:00:1e.0 Dec 26 15:59:37 box [ 0.096418] ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 7 9 10 11 12 14 15) Dec 26 15:59:37 box [ 0.097163] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 *11 12 14 15) Dec 26 15:59:37 box [ 0.097907] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 *10 11 12 14 15) Dec 26 15:59:37 box [ 0.098638] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 7 9 10 11 12 14 15) Dec 26 15:59:37 box [ 0.099377] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. Dec 26 15:59:37 box [ 0.100194] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 *9 10 11 12 14 15) Dec 26 15:59:37 box [ 0.100934] ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 9 10 *11 12 14 15) Dec 26 15:59:37 box [ 0.101665] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 9 *10 11 12 14 15) Dec 26 15:59:37 box [ 0.202525] ACPI: Power Resource [PFAN] (off) Dec 26 15:59:37 box [ 0.202881] SCSI subsystem initialized Dec 26 15:59:37 box [ 0.203088] PCI: Using ACPI for IRQ routing Dec 26 15:59:37 box [ 0.203139] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report Dec 26 15:59:37 box [ 0.228483] PCI: Bridge: 0000:00:01.0 Dec 26 15:59:37 box [ 0.228533] IO window: disabled. Dec 26 15:59:37 box [ 0.228583] MEM window: f8000000-f9ffffff Dec 26 15:59:37 box [ 0.228634] PREFETCH window: f0000000-f7ffffff Dec 26 15:59:37 box [ 0.228685] PCI: Bridge: 0000:00:03.0 Dec 26 15:59:37 box [ 0.228734] IO window: a000-afff Dec 26 15:59:37 box [ 0.228784] MEM window: fc000000-fc0fffff Dec 26 15:59:37 box [ 0.228834] PREFETCH window: disabled. Dec 26 15:59:37 box [ 0.228886] PCI: Bridge: 0000:00:1e.0 Dec 26 15:59:37 box [ 0.228935] IO window: 8000-9fff Dec 26 15:59:37 box [ 0.228985] MEM window: fa000000-fbffffff Dec 26 15:59:37 box [ 0.229036] PREFETCH window: 88000000-880fffff Dec 26 15:59:37 box [ 0.229138] NET: Registered protocol family 2 Dec 26 15:59:37 box [ 0.240374] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) Dec 26 15:59:37 box [ 0.240578] TCP established hash table entries: 131072 (order: 8, 1572864 bytes) Dec 26 15:59:37 box [ 0.241573] TCP bind hash table entries: 65536 (order: 7, 786432 bytes) Dec 26 15:59:37 box [ 0.242257] TCP: Hash tables configured (established 131072 bind 65536) Dec 26 15:59:37 box [ 0.242312] TCP reno registered Dec 26 15:59:37 box [ 0.242860] highmem bounce pool size: 64 pages Dec 26 15:59:37 box [ 0.243086] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Dec 26 15:59:37 box [ 0.243489] io scheduler noop registered Dec 26 15:59:37 box [ 0.243573] io scheduler anticipatory registered (default) Dec 26 15:59:37 box [ 0.246317] Real Time Clock Driver v1.12ac Dec 26 15:59:37 box [ 0.246370] Linux agpgart interface v0.101 (c) Dave Jones Dec 26 15:59:37 box [ 0.246462] agpgart: Detected an Intel i875 Chipset. Dec 26 15:59:37 box [ 0.250882] agpgart: AGP aperture is 128M @ 0xe8000000 Dec 26 15:59:37 box [ 0.250958] Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled Dec 26 15:59:37 box [ 0.251133] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A Dec 26 15:59:37 box [ 0.251356] Floppy drive(s): fd0 is 1.44M Dec 26 15:59:37 box [ 0.267012] FDC 0 is a post-1991 82077 Dec 26 15:59:37 box [ 0.268351] loop: loaded (max 8 devices) Dec 26 15:59:37 box [ 0.268442] Intel(R) PRO/1000 Network Driver - version 7.2.9-k4-NAPI Dec 26 15:59:37 box [ 0.268493] Copyright (c) 1999-2006 Intel Corporation. Dec 26 15:59:37 box [ 0.268600] ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 18 (level, low) -> IRQ 16 Dec 26 15:59:37 box [ 0.604067] e1000: 0000:02:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:50:8d:f1:07:38 Dec 26 15:59:37 box [ 0.834733] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection Dec 26 15:59:37 box [ 0.834892] netconsole: device eth0 not up yet, forcing it Dec 26 15:59:37 box [ 3.322054] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex Dec 26 15:59:37 box [ 3.332192] netconsole: network logging started Dec 26 15:59:37 box [ 3.332249] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 Dec 26 15:59:37 box [ 3.332302] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx Dec 26 15:59:37 box [ 3.332399] ICH5: IDE controller at PCI slot 0000:00:1f.1 Dec 26 15:59:37 box [ 3.332458] ACPI: PCI Interrupt 0000:00:1f.1[A] -> Dec 26 15:59:37 box GSI 18 (level, low) -> IRQ 16 Dec 26 15:59:37 box [ 3.332563] ICH5: chipset revision 2 Dec 26 15:59:37 box [ 3.332613] ICH5: not 100% native mode: will probe irqs later Dec 26 15:59:37 box [ 3.332671] ide0: BM-DMA at 0xf000-0xf007 Dec 26 15:59:37 box , BIOS settings: hda:DMA, hdb:pio Dec 26 15:59:37 box Dec 26 15:59:37 box [ 3.332815] ide1: BM-DMA at 0xf008-0xf00f Dec 26 15:59:37 box , BIOS settings: hdc:DMA, hdd:pio Dec 26 15:59:37 box Dec 26 15:59:38 box [ 4.003579] hda: _NEC DVD_RW ND-3550A, Dec 26 15:59:38 box ATAPI Dec 26 15:59:38 box CD/DVD-ROM Dec 26 15:59:38 box drive Dec 26 15:59:39 box [ 4.615066] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Dec 26 15:59:39 box Dec 26 15:59:39 box [ 5.286214] hdc: LITE-ON LTR-52246S, Dec 26 15:59:39 box ATAPI Dec 26 15:59:39 box CD/DVD-ROM Dec 26 15:59:39 box drive Dec 26 15:59:40 box [ 5.594037] ide1 at 0x170-0x177,0x376 on irq 15 Dec 26 15:59:40 box Dec 26 15:59:40 box [ 5.594975] hda: ATAPI Dec 26 15:59:40 box 48X Dec 26 15:59:40 box DVD-ROM Dec 26 15:59:40 box DVD-R Dec 26 15:59:40 box CD-R/RW Dec 26 15:59:40 box drive Dec 26 15:59:40 box , 2048kB Cache Dec 26 15:59:40 box , UDMA(33) Dec 26 15:59:40 box Dec 26 15:59:40 box [ 5.595335] Uniform CD-ROM driver Revision: 3.20 Dec 26 15:59:40 box [ 5.605270] hdc: ATAPI Dec 26 15:59:40 box 52X Dec 26 15:59:40 box CD-ROM Dec 26 15:59:40 box CD-R/RW Dec 26 15:59:40 box drive Dec 26 15:59:40 box , 2048kB Cache Dec 26 15:59:40 box , UDMA(33) Dec 26 15:59:40 box Dec 26 15:59:40 box [ 5.644915] ACPI: PCI Interrupt 0000:03:06.0[A] -> Dec 26 15:59:40 box GSI 22 (level, low) -> IRQ 17 Dec 26 15:59:43 box [ 8.646272] scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0 Dec 26 15:59:43 box [ 8.646274] Dec 26 15:59:43 box [ 8.646275] aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs Dec 26 15:59:43 box [ 8.646277] Dec 26 15:59:44 box [ 10.481100] ata_piix 0000:00:1f.2: MAP [ Dec 26 15:59:44 box P0 Dec 26 15:59:44 box -- Dec 26 15:59:44 box P1 Dec 26 15:59:44 box -- Dec 26 15:59:44 box ] Dec 26 15:59:44 box [ 10.481347] ACPI: PCI Interrupt 0000:00:1f.2[A] -> Dec 26 15:59:44 box GSI 18 (level, low) -> IRQ 16 Dec 26 15:59:44 box [ 10.481502] ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 Dec 26 15:59:44 box [ 10.481591] ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 Dec 26 15:59:44 box [ 10.481651] scsi1 : ata_piix Dec 26 15:59:45 box [ 10.635214] ata1.00: ATA-7, max UDMA7, 488397168 sectors: LBA48 NCQ (depth 0/32) Dec 26 15:59:45 box [ 10.635279] ata1.00: ata1: dev 0 multi count 16 Dec 26 15:59:45 box [ 10.665619] ata1.00: configured for UDMA/133 Dec 26 15:59:45 box [ 10.665674] scsi2 : ata_piix Dec 26 15:59:45 box [ 10.827315] ATA: abnormal status 0x7F on port 0xC807 Dec 26 15:59:45 box [ 10.827469] scsi 1:0:0:0: Direct-Access ATA SAMSUNG SP2504C VT10 PQ: 0 ANSI: 5 Dec 26 15:59:45 box [ 10.827651] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) Dec 26 15:59:45 box [ 10.828414] sda: Write Protect is off Dec 26 15:59:45 box [ 10.828492] SCSI device sda: drive cache: write back Dec 26 15:59:45 box [ 10.828601] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) Dec 26 15:59:45 box [ 10.828667] sda: Write Protect is off Dec 26 15:59:45 box [ 10.828746] SCSI device sda: drive cache: write back Dec 26 15:59:45 box [ 10.828798] sda: Dec 26 15:59:45 box sda1 Dec 26 15:59:45 box sda2 Dec 26 15:59:45 box Dec 26 15:59:45 box [ 10.838140] sd 1:0:0:0: Attached scsi disk sda Dec 26 15:59:45 box [ 10.838277] sd 1:0:0:0: Attached scsi generic sg0 type 0 Dec 26 15:59:45 box [ 10.840768] serio: i8042 KBD port at 0x60,0x64 irq 1 Dec 26 15:59:45 box [ 10.840824] serio: i8042 AUX port at 0x60,0x64 irq 12 Dec 26 15:59:45 box [ 10.840947] mice: PS/2 mouse device common for all mice Dec 26 15:59:45 box [ 10.841165] input: PC Speaker as /class/input/input0 Dec 26 15:59:45 box [ 10.870150] input: AT Translated Set 2 keyboard as /class/input/input1 Dec 26 15:59:45 box [ 10.874664] i2c /dev entries driver Dec 26 15:59:45 box [ 10.875229] Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28 14:07:24 2006 UTC). Dec 26 15:59:45 box [ 10.875551] ACPI: PCI Interrupt 0000:03:05.0[A] -> Dec 26 15:59:45 box GSI 21 (level, low) -> IRQ 18 Dec 26 15:59:45 box [ 10.899119] ALSA device list: Dec 26 15:59:45 box [ 10.899176] #0: SBLive! Value [CT4832] (rev.7, serial:0x80271102) at 0x9400, irq 18 Dec 26 15:59:45 box [ 10.899241] TCP cubic registered Dec 26 15:59:45 box [ 10.899313] NET: Registered protocol family 1 Dec 26 15:59:45 box [ 10.899373] NET: Registered protocol family 17 Dec 26 15:59:45 box [ 10.899465] Testing NMI watchdog ... Dec 26 15:59:45 box OK. Dec 26 15:59:45 box [ 10.909531] Starting balanced_irq Dec 26 15:59:45 box [ 10.909586] Using IPI Shortcut mode Dec 26 15:59:45 box [ 10.909755] Time: tsc clocksource has been installed. Dec 26 15:59:46 box [ 11.582043] input: ImPS/2 Generic Wheel Mouse as /class/input/input2 Dec 26 15:59:46 box [ 11.638471] UDF-fs: No VRS found Dec 26 15:59:46 box [ 11.670420] XFS mounting filesystem sda2 Dec 26 15:59:46 box [ 11.748382] VFS: Mounted root (xfs filesystem) readonly. Dec 26 15:59:46 box [ 11.748601] Freeing unused kernel memory: 216k freed Dec 26 15:59:48 box [ 13.956518] BUG: unable to handle kernel paging request Dec 26 15:59:48 box at virtual address fffb9600 Dec 26 15:59:48 box [ 13.956649] printing eip: Dec 26 15:59:48 box [ 13.956703] c0149018 Dec 26 15:59:48 box [ 13.956754] *pde = 00003067 Dec 26 15:59:48 box [ 13.956811] *pte = 00000000 Dec 26 15:59:48 box [ 13.956880] Oops: 0000 [#1] Dec 26 15:59:48 box [ 13.956944] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.957101] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.957206] CPU: 0 Dec 26 15:59:48 box [ 13.957207] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 13.957209] EFLAGS: 00010286 (2.6.19 #2) Dec 26 15:59:48 box [ 13.957381] EIP is at do_wp_page+0xec/0x431 Dec 26 15:59:48 box [ 13.957438] eax: fffb8000 ebx: fffb8000 ecx: 00000280 edx: c0003ee0 Dec 26 15:59:48 box [ 13.957505] esi: fffb9600 edi: fffb8600 ebp: c1ff06a0 esp: f7b8bed4 Dec 26 15:59:48 box [ 13.957574] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 13.957638] Process udevd (pid: 560, ti=f7b8a000 task=c2157a90 task.ti=f7b8a000) Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.957695] Stack: Dec 26 15:59:48 box c1ff3ce0 Dec 26 15:59:48 box 00000004 Dec 26 15:59:48 box 7f835065 Dec 26 15:59:48 box fffb9000 Dec 26 15:59:48 box b7e4502c Dec 26 15:59:48 box f7be11d0 Dec 26 15:59:48 box f7b84040 Dec 26 15:59:48 box c1ff3ce0 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.958140] Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box f7410914 Dec 26 15:59:48 box f741bb7c Dec 26 15:59:48 box f7b84088 Dec 26 15:59:48 box 00000007 Dec 26 15:59:48 box c014a740 Dec 26 15:59:48 box f7410914 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.958579] Dec 26 15:59:48 box f741bb7c Dec 26 15:59:48 box f7b84088 Dec 26 15:59:48 box 7f835065 Dec 26 15:59:48 box c016c06c Dec 26 15:59:48 box c21334ac Dec 26 15:59:48 box c21334ac Dec 26 15:59:48 box f7b75954 Dec 26 15:59:48 box f7b84088 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.959044] Call Trace: Dec 26 15:59:48 box [ 13.959146] [] Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 Dec 26 15:59:48 box [ 13.959246] [] Dec 26 15:59:48 box dentry_iput+0x6b/0xba Dec 26 15:59:48 box [ 13.959345] [] Dec 26 15:59:48 box mntput_no_expire+0x1c/0x7d Dec 26 15:59:48 box [ 13.959458] [] Dec 26 15:59:48 box __fput+0x174/0x1c2 Dec 26 15:59:48 box [ 13.959568] [] Dec 26 15:59:48 box do_page_fault+0x49b/0x651 Dec 26 15:59:48 box [ 13.959678] [] Dec 26 15:59:48 box do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 13.959772] [] Dec 26 15:59:48 box error_code+0x39/0x40 Dec 26 15:59:48 box [ 13.959878] [] Dec 26 15:59:48 box schedule_timeout+0xa5/0xb0 Dec 26 15:59:48 box [ 13.959987] ======================= Dec 26 15:59:48 box [ 13.960049] Code: Dec 26 15:59:48 box 24 Dec 26 15:59:48 box e8 Dec 26 15:59:48 box d1 Dec 26 15:59:48 box a9 Dec 26 15:59:48 box fc Dec 26 15:59:48 box ff Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 44 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box c7 Dec 26 15:59:48 box 44 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 04 Dec 26 15:59:48 box 04 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 8b Dec 26 15:59:48 box 54 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 1c Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 14 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box e8 Dec 26 15:59:48 box b9 Dec 26 15:59:48 box a9 Dec 26 15:59:48 box fc Dec 26 15:59:48 box ff Dec 26 15:59:48 box 89 Dec 26 15:59:48 box c3 Dec 26 15:59:48 box b9 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 04 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box c7 Dec 26 15:59:48 box 8b Dec 26 15:59:48 box 74 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box f3> Dec 26 15:59:48 box a5 Dec 26 15:59:48 box c7 Dec 26 15:59:48 box 44 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 04 Dec 26 15:59:48 box 03 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 8b Dec 26 15:59:48 box 44 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 04 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box e8 Dec 26 15:59:48 box 2a Dec 26 15:59:48 box aa Dec 26 15:59:48 box fc Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.962884] EIP: [] Dec 26 15:59:48 box do_wp_page+0xec/0x431 Dec 26 15:59:48 box SS:ESP 0068:f7b8bed4 Dec 26 15:59:48 box [ 13.963041] Dec 26 15:59:48 box note: udevd[560] exited with preempt_count 2 Dec 26 15:59:48 box [ 13.963925] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 13.963997] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 13.964061] invalid opcode: 0000 [#2] Dec 26 15:59:48 box [ 13.964114] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.964254] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.964367] CPU: 0 Dec 26 15:59:48 box [ 13.964368] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 13.964372] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 13.964534] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 13.964596] eax: 7f9e7163 ebx: fffff000 ecx: c1ff7400 edx: c0003ee0 Dec 26 15:59:48 box [ 13.964664] esi: 00000004 edi: 00000000 ebp: c1ff2860 esp: f7457ec8 Dec 26 15:59:48 box [ 13.964731] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 13.964789] Process udevd (pid: 555, ti=f7456000 task=c21b4a90 task.ti=f7456000) Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.964850] Stack: Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box f7bc2918 Dec 26 15:59:48 box c014900b Dec 26 15:59:48 box c1ff7400 Dec 26 15:59:48 box 00000004 Dec 26 15:59:48 box 7f943065 Dec 26 15:59:48 box fffb9000 Dec 26 15:59:48 box b7e4617c Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.965343] Dec 26 15:59:48 box f7bc3da0 Dec 26 15:59:48 box f7b84ac0 Dec 26 15:59:48 box c1ff7400 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box f7bc2918 Dec 26 15:59:48 box f7beab7c Dec 26 15:59:48 box f7b84b08 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.965790] Dec 26 15:59:48 box 00000007 Dec 26 15:59:48 box c014a740 Dec 26 15:59:48 box f7bc2918 Dec 26 15:59:48 box f7beab7c Dec 26 15:59:48 box f7b84b08 Dec 26 15:59:48 box 7f943065 Dec 26 15:59:48 box c016c06c Dec 26 15:59:48 box c21334ac Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.966286] Call Trace: Dec 26 15:59:48 box [ 13.966401] [] Dec 26 15:59:48 box do_wp_page+0xdf/0x431 Dec 26 15:59:48 box [ 13.966513] [] Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 Dec 26 15:59:48 box [ 13.966617] [] Dec 26 15:59:48 box dentry_iput+0x6b/0xba Dec 26 15:59:48 box [ 13.966720] [] Dec 26 15:59:48 box mntput_no_expire+0x1c/0x7d Dec 26 15:59:48 box [ 13.966836] [] Dec 26 15:59:48 box __fput+0x174/0x1c2 Dec 26 15:59:48 box [ 13.966938] [] Dec 26 15:59:48 box do_page_fault+0x49b/0x651 Dec 26 15:59:48 box [ 13.967038] [] Dec 26 15:59:48 box do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 13.967152] [] Dec 26 15:59:48 box error_code+0x39/0x40 Dec 26 15:59:48 box [ 13.967265] [] Dec 26 15:59:48 box schedule_timeout+0xa5/0xb0 Dec 26 15:59:48 box [ 13.967383] ======================= Dec 26 15:59:48 box [ 13.967450] Code: Dec 26 15:59:48 box 51 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 29 Dec 26 15:59:48 box c2 Dec 26 15:59:48 box 8b Dec 26 15:59:48 box 02 Dec 26 15:59:48 box 85 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 75 Dec 26 15:59:48 box 21 Dec 26 15:59:48 box 2b Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 80 Dec 26 15:59:48 box 9d Dec 26 15:59:48 box 52 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box f9 Dec 26 15:59:48 box 05 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box e1 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 38 Dec 26 15:59:48 box 52 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 0a Dec 26 15:59:48 box 8d Dec 26 15:59:48 box 46 Dec 26 15:59:48 box 43 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box e0 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 29 Dec 26 15:59:48 box c3 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box d8 Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 5e Dec 26 15:59:48 box c3 Dec 26 15:59:48 box f> Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 2a Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 49 Dec 26 15:59:48 box 22 Dec 26 15:59:48 box 41 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box eb Dec 26 15:59:48 box d5 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 4c Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 5e Dec 26 15:59:48 box e9 Dec 26 15:59:48 box 5c Dec 26 15:59:48 box 4a Dec 26 15:59:48 box 03 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.970382] EIP: [] Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box SS:ESP 0068:f7457ec8 Dec 26 15:59:48 box [ 13.970545] Dec 26 15:59:48 box note: udevd[555] exited with preempt_count 2 Dec 26 15:59:48 box [ 13.971027] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 13.971089] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 13.971148] invalid opcode: 0000 [#3] Dec 26 15:59:48 box [ 13.971208] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.971356] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.971447] CPU: 0 Dec 26 15:59:48 box [ 13.971449] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 13.971452] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 13.971634] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 13.971696] eax: 7f943163 ebx: fffff000 ecx: c1ff4760 edx: c0003ee4 Dec 26 15:59:48 box [ 13.971756] esi: 00000003 edi: 00000080 ebp: f7e37db8 esp: f7e37ce0 Dec 26 15:59:48 box [ 13.971824] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 13.971895] Process udevd (pid: 522, ti=f7e36000 task=c2155a90 task.ti=f7e36000) Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.971968] Stack: Dec 26 15:59:48 box f7f1d280 Dec 26 15:59:48 box 00000080 Dec 26 15:59:48 box c013d03c Dec 26 15:59:48 box c1ff4760 Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box f7aa42d0 Dec 26 15:59:48 box 00000202 Dec 26 15:59:48 box 00000080 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.972437] Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c1ff4760 Dec 26 15:59:48 box f7aa42d0 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c013dac4 Dec 26 15:59:48 box f7e37db8 Dec 26 15:59:48 box c1ff4760 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.972894] Dec 26 15:59:48 box 00000891 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box f7e37d54 Dec 26 15:59:48 box f7aa4220 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.973381] Call Trace: Dec 26 15:59:48 box [ 13.973481] [] Dec 26 15:59:48 box file_read_actor+0xbb/0xf6 Dec 26 15:59:48 box [ 13.973581] [] Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c Dec 26 15:59:48 box [ 13.973679] [] Dec 26 15:59:48 box generic_file_aio_read+0xfb/0x270 Dec 26 15:59:48 box [ 13.973774] [] Dec 26 15:59:48 box file_read_actor+0x0/0xf6 Dec 26 15:59:48 box [ 13.973871] [] Dec 26 15:59:48 box xfs_read+0x180/0x3c1 Dec 26 15:59:48 box [ 13.973971] [] Dec 26 15:59:48 box __link_path_walk+0x82c/0xda7 Dec 26 15:59:48 box [ 13.974080] [] Dec 26 15:59:48 box xfs_file_aio_read+0x70/0x84 Dec 26 15:59:48 box [ 13.974192] [] Dec 26 15:59:48 box do_sync_read+0xf0/0x126 Dec 26 15:59:48 box [ 13.974302] [] Dec 26 15:59:48 box autoremove_wake_function+0x0/0x4b Dec 26 15:59:48 box [ 13.974404] [] Dec 26 15:59:48 box try_to_wake_up+0x40/0x402 Dec 26 15:59:48 box [ 13.974500] [] Dec 26 15:59:48 box __next_cpu+0x22/0x33 Dec 26 15:59:48 box [ 13.974601] [] Dec 26 15:59:48 box vfs_read+0x9d/0x17b Dec 26 15:59:48 box [ 13.974714] [] Dec 26 15:59:48 box kernel_read+0x49/0x59 Dec 26 15:59:48 box [ 13.974820] [] Dec 26 15:59:48 box prepare_binprm+0xbf/0xf0 Dec 26 15:59:48 box [ 13.974923] [] Dec 26 15:59:48 box do_execve+0xec/0x1dc Dec 26 15:59:48 box [ 13.975019] [] Dec 26 15:59:48 box sys_execve+0x3c/0x97 Dec 26 15:59:48 box [ 13.975117] [] Dec 26 15:59:48 box syscall_call+0x7/0xb Dec 26 15:59:48 box [ 13.975234] [] Dec 26 15:59:48 box schedule_timeout+0xa5/0xb0 Dec 26 15:59:48 box [ 13.975345] ======================= Dec 26 15:59:48 box [ 13.975401] Code: Dec 26 15:59:48 box 51 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 29 Dec 26 15:59:48 box c2 Dec 26 15:59:48 box 8b Dec 26 15:59:48 box 02 Dec 26 15:59:48 box 85 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 75 Dec 26 15:59:48 box 21 Dec 26 15:59:48 box 2b Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 80 Dec 26 15:59:48 box 9d Dec 26 15:59:48 box 52 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box f9 Dec 26 15:59:48 box 05 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box e1 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 38 Dec 26 15:59:48 box 52 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 0a Dec 26 15:59:48 box 8d Dec 26 15:59:48 box 46 Dec 26 15:59:48 box 43 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box e0 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 29 Dec 26 15:59:48 box c3 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box d8 Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 5e Dec 26 15:59:48 box c3 Dec 26 15:59:48 box f> Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 2a Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 49 Dec 26 15:59:48 box 22 Dec 26 15:59:48 box 41 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box eb Dec 26 15:59:48 box d5 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 4c Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 5e Dec 26 15:59:48 box e9 Dec 26 15:59:48 box 5c Dec 26 15:59:48 box 4a Dec 26 15:59:48 box 03 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.978193] EIP: [] Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box note: udevd[522] exited with preempt_count 1 Dec 26 15:59:48 box [ 13.978847] ------------[ cut here ]------------ Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.979481] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box Dec 26 15:59:48 box c0141f9a Dec 26 15:59:48 box c046bd80 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 13.981214] Call Trace: Dec 26 15:59:48 box [ 13.982205] [] Dec 26 15:59:48 box __alloc_pages+0x4f/0x2db Dec 26 15:59:48 box [ 13.982756] [] Dec 26 15:59:48 box [ 13.982985] ======================= Dec 26 15:59:48 box 85 Dec 26 15:59:48 box 80 Dec 26 15:59:48 box e1 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 4c Dec 26 15:59:48 box 5c Dec 26 15:59:48 box [ 13.986129] Dec 26 15:59:48 box note: scsi_id[503] exited with preempt_count 1 Dec 26 15:59:48 box [ 13.986580] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 13.986947] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 13.987317] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box c013d03c Dec 26 15:59:48 box 00000080 Dec 26 15:59:48 box c1ff37c0 Dec 26 15:59:48 box f740bd54 Dec 26 15:59:48 box [ 13.988878] [] Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c Dec 26 15:59:48 box xfs_read+0x180/0x3c1 Dec 26 15:59:48 box [ 13.989838] [] Dec 26 15:59:48 box sched_balance_self+0x13b/0x2e3 Dec 26 15:59:48 box [ 13.990457] [] Dec 26 15:59:48 box syscall_call+0x7/0xb Dec 26 15:59:48 box c2 Dec 26 15:59:48 box 21 Dec 26 15:59:48 box 05 Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 43 Dec 26 15:59:48 box c3 Dec 26 15:59:48 box 41 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box Dec 26 15:59:48 box note: udevd[534] exited with preempt_count 1 Dec 26 15:59:48 box [ 13.994411] ------------[ cut here ]------------ Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 4a Dec 26 15:59:48 box [ 14.035590] Dec 26 15:59:48 box [ 14.036042] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.036206] PREEMPT Dec 26 15:59:48 box [ 14.036449] CPU: 0 Dec 26 15:59:48 box Dec 26 15:59:48 box c0148ff3 Dec 26 15:59:48 box 0805f794 Dec 26 15:59:48 box f7417080 Dec 26 15:59:48 box f7b84248 Dec 26 15:59:48 box [ 14.038497] [] Dec 26 15:59:48 box do_page_fault+0x0/0x651 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box 75 Dec 26 15:59:48 box e1 Dec 26 15:59:48 box 0a Dec 26 15:59:48 box 5e Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box [ 14.042223] Dec 26 15:59:48 box [ 14.042667] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.042856] PREEMPT Dec 26 15:59:48 box [ 14.043120] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.043476] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box c1ff1d80 Dec 26 15:59:48 box Dec 26 15:59:48 box f7b08080 Dec 26 15:59:48 box c014a740 Dec 26 15:59:48 box [ 14.045003] Call Trace: Dec 26 15:59:48 box [ 14.045341] [] Dec 26 15:59:48 box error_code+0x39/0x40 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 8d Dec 26 15:59:48 box 29 Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 41 Dec 26 15:59:48 box 5e Dec 26 15:59:48 box 00 Dec 26 15:59:48 box Dec 26 15:59:48 box note: udevd[474] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.049495] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.049551] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.050516] invalid opcode: 0000 [#13] Dec 26 15:59:48 box [ 14.050573] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box [ 14.050833] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 14.051183] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box c046bd80 Dec 26 15:59:48 box [ 14.052157] Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box [ 14.052822] [] Dec 26 15:59:48 box [ 14.053047] [] Dec 26 15:59:48 box do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 14.053672] [] Dec 26 15:59:48 box file_read_actor+0x0/0xf6 Dec 26 15:59:48 box [ 14.054299] [] Dec 26 15:59:48 box vfs_read+0x9d/0x17b Dec 26 15:59:48 box [ 14.054931] [] Dec 26 15:59:48 box 8b Dec 26 15:59:48 box 9d Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 0a Dec 26 15:59:48 box 0c Dec 26 15:59:48 box f> Dec 26 15:59:48 box 41 Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 00 Dec 26 15:59:48 box note: udevd[518] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.058569] ------------[ cut here ]------------ Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.059035] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box [ 14.059997] Dec 26 15:59:48 box [ 14.060465] Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.061279] [] Dec 26 15:59:48 box do_page_fault+0x49b/0x651 Dec 26 15:59:48 box [ 14.061926] [] Dec 26 15:59:48 box [ 14.062146] [] Dec 26 15:59:48 box get_unused_fd+0xbe/0xcf Dec 26 15:59:48 box [ 14.063032] [] Dec 26 15:59:48 box syscall_call+0x7/0xb Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 2b Dec 26 15:59:48 box c1 Dec 26 15:59:48 box 38 Dec 26 15:59:48 box 43 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 49 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box note: udevd[488] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.068364] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.068432] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.068492] invalid opcode: 0000 [#15] Dec 26 15:59:48 box [ 14.068555] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.068808] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.069161] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box fffb9000 Dec 26 15:59:48 box c1ff5ca0 Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box 00000db2 Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 Dec 26 15:59:48 box do_page_fault+0x49b/0x651 Dec 26 15:59:48 box [ 14.071491] [] Dec 26 15:59:48 box [ 14.071767] Code: Dec 26 15:59:48 box 75 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box d8 Dec 26 15:59:48 box eb Dec 26 15:59:48 box [ 14.074634] EIP: [] Dec 26 15:59:48 box note: S03udev[632] exited with preempt_count 2 Dec 26 15:59:48 box [ 14.076251] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.076333] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.076399] invalid opcode: 0000 [#16] Dec 26 15:59:48 box [ 14.076465] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box [ 14.076615] Modules linked in: Dec 26 15:59:48 box [ 14.077088] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.077205] Stack: Dec 26 15:59:48 box f7a3f160 Dec 26 15:59:48 box f7e83dd0 Dec 26 15:59:48 box [ 14.078163] Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.078858] [] Dec 26 15:59:48 box [ 14.079088] [] Dec 26 15:59:48 box [ 14.079511] [] Dec 26 15:59:48 box autoremove_wake_function+0x0/0x4b Dec 26 15:59:48 box sys_read+0x4b/0x74 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box 00000080 Dec 26 15:59:48 box f7b7eed0 Dec 26 15:59:48 box 00001000 Dec 26 15:59:48 box Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c Dec 26 15:59:48 box xfs_read+0x180/0x3c1 Dec 26 15:59:48 box do_sync_read+0xf0/0x126 Dec 26 15:59:48 box [ 14.097192] [] Dec 26 15:59:48 box prepare_binprm+0xbf/0xf0 Dec 26 15:59:48 box [ 14.097817] [] Dec 26 15:59:48 box 29 Dec 26 15:59:48 box 2b Dec 26 15:59:48 box f9 Dec 26 15:59:48 box 52 Dec 26 15:59:48 box 43 Dec 26 15:59:48 box 5e Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 4a Dec 26 15:59:48 box note: udevd[497] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.101348] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.101407] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.101781] CPU: 0 Dec 26 15:59:48 box [ 14.102144] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box f7b77174 Dec 26 15:59:48 box Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box c014a740 Dec 26 15:59:48 box c224fa90 Dec 26 15:59:48 box [ 14.104054] [] Dec 26 15:59:48 box [ 14.104285] [] Dec 26 15:59:48 box [ 14.104689] Code: Dec 26 15:59:48 box 02 Dec 26 15:59:48 box 9d Dec 26 15:59:48 box 05 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box 43 Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 41 Dec 26 15:59:48 box e9 Dec 26 15:59:48 box 5c Dec 26 15:59:48 box Dec 26 15:59:48 box note: udevd[494] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.108249] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.108721] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.109013] esi: 00000003 edi: 00000080 ebp: f7b8fdb8 esp: f7b8fce0 Dec 26 15:59:48 box c013d03c Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box f7b8fdb8 Dec 26 15:59:48 box 00000006 Dec 26 15:59:48 box [ 14.110608] Call Trace: Dec 26 15:59:48 box generic_file_aio_read+0xfb/0x270 Dec 26 15:59:48 box [ 14.111271] [] Dec 26 15:59:48 box autoremove_wake_function+0x0/0x4b Dec 26 15:59:48 box [ 14.111881] [] Dec 26 15:59:48 box prepare_binprm+0xbf/0xf0 Dec 26 15:59:48 box schedule_timeout+0xa5/0xb0 Dec 26 15:59:48 box c2 Dec 26 15:59:48 box 9d Dec 26 15:59:48 box 05 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box f> Dec 26 15:59:48 box d5 Dec 26 15:59:48 box 5e Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.115962] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.116030] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.116373] CPU: 0 Dec 26 15:59:48 box [ 14.116744] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.116857] Stack: Dec 26 15:59:48 box 0805b2d0 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c014a740 Dec 26 15:59:48 box c046a6a0 Dec 26 15:59:48 box [ 14.118469] [] Dec 26 15:59:48 box memmove+0x3f/0x48 Dec 26 15:59:48 box [ 14.119445] [] Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 Dec 26 15:59:48 box file_free_rcu+0x18/0x1c Dec 26 15:59:48 box do_page_fault+0x0/0x651 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box 85 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 0a Dec 26 15:59:48 box 0c Dec 26 15:59:48 box f> Dec 26 15:59:48 box 41 Dec 26 15:59:48 box 5e Dec 26 15:59:48 box Dec 26 15:59:48 box note: udevd[496] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.123658] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.123994] Modules linked in: Dec 26 15:59:48 box [ 14.124267] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.124463] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box c1ff47c0 Dec 26 15:59:48 box Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box [ 14.126032] Call Trace: Dec 26 15:59:48 box [ 14.126356] [] Dec 26 15:59:48 box __link_path_walk+0x82c/0xda7 Dec 26 15:59:48 box [ 14.126999] [] Dec 26 15:59:48 box [ 14.127331] [] Dec 26 15:59:48 box prepare_binprm+0xbf/0xf0 Dec 26 15:59:48 box [ 14.127996] [] Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 75 Dec 26 15:59:48 box 52 Dec 26 15:59:48 box 52 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box c3 Dec 26 15:59:48 box eb Dec 26 15:59:48 box 5c Dec 26 15:59:48 box SS:ESP 0068:f7b97ce0 Dec 26 15:59:48 box [ 14.131704] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.131830] invalid opcode: 0000 [#23] Dec 26 15:59:48 box [ 14.132078] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 14.132134] Call Trace: Dec 26 15:59:48 box [ 14.132145] [] wake_bit_function+0x0/0x34 Dec 26 15:59:48 box [ 14.132196] [] do_sync_read+0xf0/0x126 Dec 26 15:59:48 box [ 14.132227] [] kernel_read+0x49/0x59 Dec 26 15:59:48 box [ 14.132325] <6>note: udevd[535] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.132544] PREEMPT SMP Dec 26 15:59:48 box [ 14.132570] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.132620] [] do_wp_page+0xc7/0x431 Dec 26 15:59:48 box [ 14.132662] [] error_code+0x39/0x40 Dec 26 15:59:48 box [ 14.132890] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.132926] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.132962] [] file_read_actor+0xbb/0xf6 Dec 26 15:59:48 box [ 14.132996] [] __link_path_walk+0x82c/0xda7 Dec 26 15:59:48 box [ 14.133040] [] prepare_binprm+0xbf/0xf0 Dec 26 15:59:48 box [ 14.133066] ======================= Dec 26 15:59:48 box [ 14.133124] EIP: [] kmap_atomic+0x7f/0x94 SS:ESP 0068:f74b1ce0 Dec 26 15:59:48 box [ 14.133276] PREEMPT SMP Dec 26 15:59:48 box [ 14.133291] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.133327] 00000000 c1ff47c0 f7453d7c 00000000 c013dac4 f7453db8 c1ff47c0 00000000 Dec 26 15:59:48 box [ 14.139180] Call Trace: Dec 26 15:59:48 box [ 14.139198] [] do_wp_page+0x386/0x431 Dec 26 15:59:48 box [ 14.139223] ======================= Dec 26 15:59:48 box [ 14.139472] [] skb_queue_purge+0x1a/0x23 Dec 26 15:59:48 box [ 14.139508] [] pipe_read_release+0x24/0x36 Dec 26 15:59:48 box [ 14.139557] [] do_invalid_op+0xab/0xb4 Dec 26 15:59:48 box [ 14.139584] [] bitmap_parse_user+0x37/0x57 Dec 26 15:59:48 box [ 14.139628] [] syscall_call+0x7/0xb Dec 26 15:59:48 box [ 14.139730] PREEMPT SMP Dec 26 15:59:48 box [ 14.139761] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.135224] Call Trace: Dec 26 15:59:48 box [ 14.135248] [] xfs_read+0x180/0x3c1 Dec 26 15:59:48 box [ 14.135279] [] try_to_wake_up+0x40/0x402 Dec 26 15:59:48 box [ 14.135405] <6>note: udevd[639] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.135599] invalid opcode: 0000 [#32] Dec 26 15:59:48 box [ 14.135675] Call Trace: Dec 26 15:59:48 box [ 14.135688] [] do_wait+0x55a/0xb55 Dec 26 15:59:48 box [ 14.135719] ======================= Dec 26 15:59:48 box [ 14.135980] PREEMPT SMP Dec 26 15:59:48 box [ 14.135993] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.136044] Call Trace: Dec 26 15:59:48 box [ 14.136070] [] do_page_fault+0x49b/0x651 Dec 26 15:59:48 box [ 14.136075] [] do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 14.136080] [] error_code+0x39/0x40 Dec 26 15:59:48 box [ 14.136089] ======================= Dec 26 15:59:48 box [ 14.136289] invalid opcode: 0000 [#34] Dec 26 15:59:48 box [ 14.136309] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.136366] Call Trace: Dec 26 15:59:48 box [ 14.136382] [] do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 14.136432] [] kmap_high+0x60/0x1f7 Dec 26 15:59:48 box [ 14.136462] [] search_binary_handler+0xab/0x266 Dec 26 15:59:48 box [ 14.136550] <6>note: modprobe[665] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.136648] PREEMPT SMP Dec 26 15:59:48 box [ 14.136683] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.136730] Call Trace: Dec 26 15:59:48 box [ 14.136767] [] error_code+0x39/0x40 Dec 26 15:59:48 box [ 14.136839] <6>note: udevd[657] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.136994] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.137051] Call Trace: Dec 26 15:59:48 box [ 14.137077] [] generic_file_aio_read+0xfb/0x270 Dec 26 15:59:48 box [ 14.137117] [] try_to_wake_up+0x40/0x402 Dec 26 15:59:48 box [ 14.137145] [] sys_execve+0x3c/0x97 Dec 26 15:59:48 box [ 14.137396] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.137473] Call Trace: Dec 26 15:59:48 box [ 14.137475] [] do_wp_page+0xc7/0x431 Dec 26 15:59:48 box [ 14.137504] [] schedule_timeout+0xa5/0xb0 Dec 26 15:59:48 box [ 14.137820] invalid opcode: 0000 [#38] Dec 26 15:59:48 box [ 14.137837] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.137841] eax: 7fe86163 ebx: fffff000 ecx: c1fff060 edx: c0003ee4 Dec 26 15:59:48 box [ 14.137847] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.137870] 00000007 c014a740 f74c0180 f744f080 f741f088 7ff83045 00000280 c2248030 Dec 26 15:59:48 box [ 14.137909] [] error_code+0x39/0x40 Dec 26 15:59:48 box [ 14.137965] EIP: [] kmap_atomic+0x7f/0x94 SS:ESP 0068:f74dbec8 Dec 26 15:59:48 box [ 14.138258] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.138275] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.138321] [] __handle_mm_fault+0x6fa/0x997 Dec 26 15:59:48 box [ 14.138353] [] do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 14.138622] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.138644] CPU: 0 Dec 26 15:59:48 box [ 14.138710] Call Trace: Dec 26 15:59:48 box [ 14.138713] [] do_wp_page+0xc7/0x431 Dec 26 15:59:48 box [ 14.138754] ======================= Dec 26 15:59:48 box [ 14.139107] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.139127] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.139180] Call Trace: Dec 26 15:59:48 box [ 14.139204] [] autoremove_wake_function+0x0/0x4b Dec 26 15:59:48 box [ 14.139288] <6>note: udevd[465] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.139489] [] __mutex_lock_slowpath+0x50/0x89 Dec 26 15:59:48 box [ 14.139553] [] do_invalid_op+0x0/0xb4 Dec 26 15:59:48 box [ 14.139578] [] error_code+0x39/0x40 Dec 26 15:59:48 box [ 14.139624] [] sys_write+0x4b/0x74 Dec 26 15:59:48 box [ 14.139737] CPU: 0 Dec 26 15:59:48 box [ 14.139761] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.139804] Call Trace: Dec 26 15:59:48 box [ 14.139807] [] do_wp_page+0xc7/0x431 Dec 26 15:59:48 box [ 14.139812] [] __handle_mm_fault+0x6fa/0x997 Dec 26 15:59:48 box [ 14.139823] [] __fput+0x174/0x1c2 Dec 26 15:59:48 box [ 14.139852] ======================= Dec 26 15:59:48 box [ 14.140230] PREEMPT SMP Dec 26 15:59:48 box [ 14.140261] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.140303] Call Trace: Dec 26 15:59:48 box [ 14.140325] [] do_page_fault+0x49b/0x651 Dec 26 15:59:48 box [ 14.140412] <6>note: udevd[656] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.140621] Modules linked in: Dec 26 15:59:48 box [ 14.140644] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.140684] Call Trace: Dec 26 15:59:48 box [ 14.140713] [] do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 14.140978] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.140994] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.141051] Call Trace: Dec 26 15:59:48 box [ 14.141076] [] do_page_fault+0x49b/0x651 Dec 26 15:59:48 box [ 14.141158] <6>note: udevd[654] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.141911] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.141967] Call Trace: Dec 26 15:59:48 box [ 14.142009] [] do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 14.170666] ------------[ cut here ]------------ Dec 26 15:59:48 box SMP Dec 26 15:59:48 box [ 14.171329] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.171432] Stack: Dec 26 15:59:48 box [ 14.171816] Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab Dec 26 15:59:48 box do_page_fault+0x49b/0x651 Dec 26 15:59:48 box error_code+0x39/0x40 Dec 26 15:59:48 box [ 14.174004] ======================= Dec 26 15:59:48 box [ 14.174052] Code: Dec 26 15:59:48 box 75 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 52 Dec 26 15:59:48 box 43 Dec 26 15:59:48 box f> Dec 26 15:59:48 box 41 Dec 26 15:59:48 box Dec 26 15:59:48 box note: udevd[495] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.183278] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.183348] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.183407] invalid opcode: 0000 [#48] Dec 26 15:59:48 box [ 14.183465] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.183605] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.183702] CPU: 0 Dec 26 15:59:48 box [ 14.183703] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.183704] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 14.183854] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.183905] eax: 7fe86163 ebx: fffff000 ecx: c1ff3fe0 edx: c0003ee4 Dec 26 15:59:48 box [ 14.183958] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f7539e64 Dec 26 15:59:48 box [ 14.184010] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.184060] Process modprobe (pid: 681, ti=f7538000 task=c224ea90 task.ti=f7538000) Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.184114] Stack: Dec 26 15:59:48 box c1ff3fe0 Dec 26 15:59:48 box c1ff3fe0 Dec 26 15:59:48 box c0141f9a Dec 26 15:59:48 box c1ff3fe0 Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box 000001b2 Dec 26 15:59:48 box c046bc00 Dec 26 15:59:48 box 000280d2 Dec 26 15:59:48 box [ 14.185342] [] Dec 26 15:59:48 box [ 14.185695] [] Dec 26 15:59:48 box [ 14.185955] ======================= Dec 26 15:59:48 box 75 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 5b Dec 26 15:59:48 box SS:ESP 0068:f7539e64 Dec 26 15:59:48 box [ 14.192143] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.192211] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.192264] invalid opcode: 0000 [#49] Dec 26 15:59:48 box [ 14.192318] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.192440] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.192529] CPU: 0 Dec 26 15:59:48 box [ 14.192531] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.192533] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 14.192695] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.192754] eax: 7fe86163 ebx: fffff000 ecx: c1ffbba0 edx: c0003ee4 Dec 26 15:59:48 box [ 14.192871] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box c1ffbba0 Dec 26 15:59:48 box [ 14.193385] Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab Dec 26 15:59:48 box [ 14.194689] [] Dec 26 15:59:48 box file_read_actor+0x22/0xf6 Dec 26 15:59:48 box [ 14.195304] [] Dec 26 15:59:48 box [ 14.195566] [] Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 80 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box 0a Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 5b Dec 26 15:59:48 box SS:ESP 0068:f7533bb4 Dec 26 15:59:48 box [ 14.211977] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.212045] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.212103] invalid opcode: 0000 [#50] Dec 26 15:59:48 box [ 14.212159] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.212290] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.212376] CPU: 0 Dec 26 15:59:48 box [ 14.212377] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.212378] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 14.212527] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.212577] eax: 7fe86163 ebx: fffff000 ecx: c1ff61e0 edx: c0003ee4 Dec 26 15:59:48 box [ 14.212630] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f7535bb4 Dec 26 15:59:48 box [ 14.212683] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.212733] Process modprobe (pid: 679, ti=f7534000 task=c21d6030 task.ti=f7534000) Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.212786] Stack: Dec 26 15:59:48 box c1ff61e0 Dec 26 15:59:48 box c1ff61e0 Dec 26 15:59:48 box c0141f9a Dec 26 15:59:48 box c1ff61e0 Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box 000001b2 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000044 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.213165] Dec 26 15:59:48 box c046bd80 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c046bc00 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.213544] Dec 26 15:59:48 box 000280d2 Dec 26 15:59:48 box c046bfa0 Dec 26 15:59:48 box 00000282 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box f7535c50 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box c046bfa0 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.213923] Call Trace: Dec 26 15:59:48 box [ 14.214014] [] Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab Dec 26 15:59:48 box __handle_mm_fault+0x83a/0x997 Dec 26 15:59:48 box do_page_fault+0x0/0x651 Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c Dec 26 15:59:48 box get_unused_fd+0xbe/0xcf Dec 26 15:59:48 box [ 14.215500] [] Dec 26 15:59:48 box [ 14.215759] ======================= Dec 26 15:59:48 box 21 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box d8 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 5b Dec 26 15:59:48 box SS:ESP 0068:f7535bb4 Dec 26 15:59:48 box [ 14.218603] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.218708] invalid opcode: 0000 [#51] Dec 26 15:59:48 box [ 14.219105] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box f74fe168 Dec 26 15:59:48 box Dec 26 15:59:48 box Dec 26 15:59:48 box f74fbcc8 Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 Dec 26 15:59:48 box do_page_fault+0x0/0x651 Dec 26 15:59:48 box 29 Dec 26 15:59:48 box 21 Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 8d Dec 26 15:59:48 box 5e Dec 26 15:59:48 box eb Dec 26 15:59:48 box 4a Dec 26 15:59:48 box [ 14.223732] Dec 26 15:59:48 box [ 14.233317] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.233377] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.233433] invalid opcode: 0000 [#52] Dec 26 15:59:48 box [ 14.233486] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.233610] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.233696] CPU: 0 Dec 26 15:59:48 box [ 14.233697] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.233698] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 14.233844] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.233895] eax: 7fe86163 ebx: fffff000 ecx: c1ff5680 edx: c0003ee4 Dec 26 15:59:48 box [ 14.233948] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f7537bb4 Dec 26 15:59:48 box [ 14.234692] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.234742] Process modprobe (pid: 680, ti=f7536000 task=f7476560 task.ti=f7536000) Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.234796] Stack: Dec 26 15:59:48 box c1ff5680 Dec 26 15:59:48 box c1ff5680 Dec 26 15:59:48 box c0141f9a Dec 26 15:59:48 box c1ff5680 Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box 000001b2 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000044 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.235175] Dec 26 15:59:48 box c046bd80 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c046bc00 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.235552] Dec 26 15:59:48 box 000280d2 Dec 26 15:59:48 box c046bfa0 Dec 26 15:59:48 box [ 14.236198] [] Dec 26 15:59:48 box __sched_text_start+0x40c/0xaf3 Dec 26 15:59:48 box file_read_actor+0x22/0xf6 Dec 26 15:59:48 box [ 14.237192] [] Dec 26 15:59:48 box [ 14.237540] [] Dec 26 15:59:48 box [ 14.237798] [] Dec 26 15:59:48 box 85 Dec 26 15:59:48 box f9 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box e0 Dec 26 15:59:48 box 2a Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 03 Dec 26 15:59:48 box note: modprobe[680] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.240812] invalid opcode: 0000 [#53] Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.241410] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box c0148ff3 Dec 26 15:59:48 box c1ff7b60 Dec 26 15:59:48 box f7b90168 Dec 26 15:59:48 box do_wp_page+0xc7/0x431 Dec 26 15:59:48 box [ 14.243180] [] Dec 26 15:59:48 box c0 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 38 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 22 Dec 26 15:59:48 box e9 Dec 26 15:59:48 box note: udevd[671] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.265589] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.265643] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.265693] invalid opcode: 0000 [#54] Dec 26 15:59:48 box [ 14.265742] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.265858] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.265942] CPU: 0 Dec 26 15:59:48 box [ 14.265943] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.265944] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 14.266092] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.266142] eax: 7fe86163 ebx: fffff000 ecx: c1ff7740 edx: c0003ee4 Dec 26 15:59:48 box [ 14.266195] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f753bbb4 Dec 26 15:59:48 box [ 14.266247] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.266297] Process modprobe (pid: 682, ti=f753a000 task=f7476a90 task.ti=f753a000) Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.266350] Stack: Dec 26 15:59:48 box c1ff7740 Dec 26 15:59:48 box c1ff7740 Dec 26 15:59:48 box c0141f9a Dec 26 15:59:48 box c1ff7740 Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box 000001b2 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000044 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.266728] Dec 26 15:59:48 box c046bd80 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c046bc00 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.267106] Dec 26 15:59:48 box 000280d2 Dec 26 15:59:48 box c046bfa0 Dec 26 15:59:48 box 00000282 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c0515324 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box c046bfa0 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.267483] Call Trace: Dec 26 15:59:48 box [ 14.267574] [] Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab Dec 26 15:59:48 box [ 14.267663] [] Dec 26 15:59:48 box __alloc_pages+0x4f/0x2db Dec 26 15:59:48 box [ 14.267750] [] Dec 26 15:59:48 box __handle_mm_fault+0x83a/0x997 Dec 26 15:59:48 box [ 14.267839] [] Dec 26 15:59:48 box __sched_text_start+0x40c/0xaf3 Dec 26 15:59:48 box [ 14.267927] [] Dec 26 15:59:48 box __sched_text_start+0x43c/0xaf3 Dec 26 15:59:48 box [ 14.268014] [] Dec 26 15:59:48 box do_page_fault+0x49b/0x651 Dec 26 15:59:48 box [ 14.268102] [] Dec 26 15:59:48 box do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 14.268188] [] Dec 26 15:59:48 box error_code+0x39/0x40 Dec 26 15:59:48 box [ 14.268274] [] Dec 26 15:59:48 box file_read_actor+0x22/0xf6 Dec 26 15:59:48 box [ 14.268362] [] Dec 26 15:59:48 box wake_bit_function+0x0/0x34 Dec 26 15:59:48 box [ 14.268449] [] Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c Dec 26 15:59:48 box [ 14.268538] [] Dec 26 15:59:48 box generic_file_aio_read+0xfb/0x270 Dec 26 15:59:48 box [ 14.268625] [] Dec 26 15:59:48 box file_read_actor+0x0/0xf6 Dec 26 15:59:48 box [ 14.268711] [] Dec 26 15:59:48 box xfs_read+0x180/0x3c1 Dec 26 15:59:48 box get_unused_fd+0xbe/0xcf Dec 26 15:59:48 box sys_read+0x4b/0x74 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box f9 Dec 26 15:59:48 box 38 Dec 26 15:59:48 box 52 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 5e Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 00 Dec 26 15:59:48 box [ 14.442714] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.442774] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.442825] invalid opcode: 0000 [#55] Dec 26 15:59:48 box [ 14.442874] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.442991] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.443077] CPU: 0 Dec 26 15:59:48 box [ 14.443078] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.443079] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 14.443228] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.443278] eax: 7fe86163 ebx: fffff000 ecx: c1ff5040 edx: c0003ee4 Dec 26 15:59:48 box [ 14.443332] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f78b3e64 Dec 26 15:59:48 box [ 14.443384] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.443434] Process rc (pid: 377, ti=f78b2000 task=c2155030 task.ti=f78b2000) Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.443478] Stack: Dec 26 15:59:48 box c1ff5040 Dec 26 15:59:48 box c1ff5040 Dec 26 15:59:48 box c0141f9a Dec 26 15:59:48 box c1ff5040 Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box 000001b2 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000044 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.443858] Dec 26 15:59:48 box c046bd80 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c046bc00 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000002 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.444236] Dec 26 15:59:48 box 000280d2 Dec 26 15:59:48 box c046bfa0 Dec 26 15:59:48 box 00000282 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box c046bfa0 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.444616] Call Trace: Dec 26 15:59:48 box [ 14.444707] [] Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab Dec 26 15:59:48 box [ 14.444797] [] Dec 26 15:59:48 box __alloc_pages+0x4f/0x2db Dec 26 15:59:48 box [ 14.444883] [] Dec 26 15:59:48 box cp_new_stat64+0x103/0x115 Dec 26 15:59:48 box [ 14.444971] [] Dec 26 15:59:48 box __handle_mm_fault+0x83a/0x997 Dec 26 15:59:48 box [ 14.445059] [] Dec 26 15:59:48 box vma_merge+0x136/0x1c5 Dec 26 15:59:48 box [ 14.445146] [] Dec 26 15:59:48 box do_brk+0x17b/0x219 Dec 26 15:59:48 box [ 14.445232] [] Dec 26 15:59:48 box do_page_fault+0x49b/0x651 Dec 26 15:59:48 box [ 14.445319] [] Dec 26 15:59:48 box do_page_fault+0x0/0x651 Dec 26 15:59:48 box [ 14.445405] [] Dec 26 15:59:48 box error_code+0x39/0x40 Dec 26 15:59:48 box [ 14.445492] ======================= Dec 26 15:59:48 box [ 14.445541] Code: Dec 26 15:59:48 box 51 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 29 Dec 26 15:59:48 box c2 Dec 26 15:59:48 box 8b Dec 26 15:59:48 box 02 Dec 26 15:59:48 box 85 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 75 Dec 26 15:59:48 box 21 Dec 26 15:59:48 box 2b Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 80 Dec 26 15:59:48 box 9d Dec 26 15:59:48 box 52 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box f9 Dec 26 15:59:48 box 05 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box e1 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 38 Dec 26 15:59:48 box 52 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 0a Dec 26 15:59:48 box 8d Dec 26 15:59:48 box 46 Dec 26 15:59:48 box 43 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box e0 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 29 Dec 26 15:59:48 box c3 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box d8 Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 5e Dec 26 15:59:48 box c3 Dec 26 15:59:48 box f> Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 2a Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 49 Dec 26 15:59:48 box 22 Dec 26 15:59:48 box 41 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box eb Dec 26 15:59:48 box d5 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 4c Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 5e Dec 26 15:59:48 box e9 Dec 26 15:59:48 box 5c Dec 26 15:59:48 box 4a Dec 26 15:59:48 box 03 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.447903] EIP: [] Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box SS:ESP 0068:f78b3e64 Dec 26 15:59:48 box [ 14.448028] Dec 26 15:59:48 box note: rc[377] exited with preempt_count 1 Dec 26 15:59:48 box [ 14.448896] ------------[ cut here ]------------ Dec 26 15:59:48 box [ 14.448953] kernel BUG at arch/i386/mm/highmem.c:42! Dec 26 15:59:48 box [ 14.449004] invalid opcode: 0000 [#56] Dec 26 15:59:48 box [ 14.449053] PREEMPT Dec 26 15:59:48 box SMP Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.449170] Modules linked in: Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.449255] CPU: 0 Dec 26 15:59:48 box [ 14.449256] EIP: 0060:[] Not tainted VLI Dec 26 15:59:48 box [ 14.449257] EFLAGS: 00010206 (2.6.19 #2) Dec 26 15:59:48 box [ 14.449406] EIP is at kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box [ 14.449456] eax: 7fe86163 ebx: fffff000 ecx: c1fff360 edx: c0003ee4 Dec 26 15:59:48 box [ 14.449509] esi: 00000003 edi: 00000180 ebp: c2121e0c esp: c2121d34 Dec 26 15:59:48 box [ 14.449562] ds: 007b es: 007b ss: 0068 Dec 26 15:59:48 box [ 14.449614] Process init (pid: 1, ti=c2120000 task=c211ca90 task.ti=c2120000) Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.449658] Stack: Dec 26 15:59:48 box b7f68460 Dec 26 15:59:48 box 00000180 Dec 26 15:59:48 box c013d03c Dec 26 15:59:48 box c1fff360 Dec 26 15:59:48 box 00000003 Dec 26 15:59:48 box c1fff360 Dec 26 15:59:48 box c01443c5 Dec 26 15:59:48 box 00000180 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.450036] Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c1fff360 Dec 26 15:59:48 box c2121dd0 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box c013dac4 Dec 26 15:59:48 box c2121e0c Dec 26 15:59:48 box c1fff360 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.450413] Dec 26 15:59:48 box 00001000 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box c2121da8 Dec 26 15:59:48 box f796f820 Dec 26 15:59:48 box 00000005 Dec 26 15:59:48 box 00000000 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box 00000001 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.450793] Call Trace: Dec 26 15:59:48 box [ 14.450884] [] Dec 26 15:59:48 box file_read_actor+0xbb/0xf6 Dec 26 15:59:48 box [ 14.450973] [] Dec 26 15:59:48 box activate_page+0x1e/0x99 Dec 26 15:59:48 box [ 14.451060] [] Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c Dec 26 15:59:48 box [ 14.451149] [] Dec 26 15:59:48 box generic_file_aio_read+0xfb/0x270 Dec 26 15:59:48 box [ 14.451237] [] Dec 26 15:59:48 box file_read_actor+0x0/0xf6 Dec 26 15:59:48 box [ 14.452013] [] Dec 26 15:59:48 box xfs_read+0x180/0x3c1 Dec 26 15:59:48 box [ 14.452100] [] Dec 26 15:59:48 box get_unused_fd+0xbe/0xcf Dec 26 15:59:48 box [ 14.452189] [] Dec 26 15:59:48 box xfs_file_aio_read+0x70/0x84 Dec 26 15:59:48 box [ 14.452276] [] Dec 26 15:59:48 box do_sync_read+0xf0/0x126 Dec 26 15:59:48 box [ 14.452362] [] Dec 26 15:59:48 box enqueue_hrtimer+0x52/0x83 Dec 26 15:59:48 box [ 14.452449] [] Dec 26 15:59:48 box autoremove_wake_function+0x0/0x4b Dec 26 15:59:48 box [ 14.452537] [] Dec 26 15:59:48 box fcntl_setlk+0x44/0x231 Dec 26 15:59:48 box [ 14.452626] [] Dec 26 15:59:48 box vfs_read+0x9d/0x17b Dec 26 15:59:48 box [ 14.452711] [] Dec 26 15:59:48 box sys_read+0x4b/0x74 Dec 26 15:59:48 box [ 14.452796] [] Dec 26 15:59:48 box syscall_call+0x7/0xb Dec 26 15:59:48 box [ 14.452882] ======================= Dec 26 15:59:48 box [ 14.452930] Code: Dec 26 15:59:48 box 51 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 29 Dec 26 15:59:48 box c2 Dec 26 15:59:48 box 8b Dec 26 15:59:48 box 02 Dec 26 15:59:48 box 85 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 75 Dec 26 15:59:48 box 21 Dec 26 15:59:48 box 2b Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 80 Dec 26 15:59:48 box 9d Dec 26 15:59:48 box 52 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box f9 Dec 26 15:59:48 box 05 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box e1 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 0d Dec 26 15:59:48 box 38 Dec 26 15:59:48 box 52 Dec 26 15:59:48 box 51 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 0a Dec 26 15:59:48 box 8d Dec 26 15:59:48 box 46 Dec 26 15:59:48 box 43 Dec 26 15:59:48 box c1 Dec 26 15:59:48 box e0 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 29 Dec 26 15:59:48 box c3 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box d8 Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 5e Dec 26 15:59:48 box c3 Dec 26 15:59:48 box f> Dec 26 15:59:48 box 0b Dec 26 15:59:48 box 2a Dec 26 15:59:48 box 00 Dec 26 15:59:48 box 49 Dec 26 15:59:48 box 22 Dec 26 15:59:48 box 41 Dec 26 15:59:48 box c0 Dec 26 15:59:48 box eb Dec 26 15:59:48 box d5 Dec 26 15:59:48 box 89 Dec 26 15:59:48 box 4c Dec 26 15:59:48 box 24 Dec 26 15:59:48 box 0c Dec 26 15:59:48 box 5b Dec 26 15:59:48 box 5e Dec 26 15:59:48 box e9 Dec 26 15:59:48 box 5c Dec 26 15:59:48 box 4a Dec 26 15:59:48 box 03 Dec 26 15:59:48 box 00 Dec 26 15:59:48 box Dec 26 15:59:48 box [ 14.455288] EIP: [] Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 Dec 26 15:59:48 box SS:ESP 0068:c2121d34 Dec 26 15:59:48 box [ 14.455412] Dec 26 15:59:48 box Kernel panic - not syncing: Attempted to kill init! Dec 26 15:59:49 box [ 14.455556] From owner-xfs@oss.sgi.com Tue Dec 26 17:38:39 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 26 Dec 2006 17:38:44 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBR1ccqw005965 for ; Tue, 26 Dec 2006 17:38:38 -0800 Received: by wx-out-0506.google.com with SMTP id t4so3838380wxc for ; Tue, 26 Dec 2006 17:37:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:x-face:mime-version:content-type:content-transfer-encoding:message-id:sender; b=l6XIePbvxds2Zkdj3G8GjNMlQ2aBLNFrvVcI35xcKpWaMMa1UunHicSpTd3JeEBB8W38fM7HjCYh/BZF03Xbv1EkpkEKhHFtTQHCgkdaOBt6GthF8gX9tF8Hw1ZdTiLvLIp5LMl+RLmqLOkkBGvUw/UZmteKf7uu9pbpNnNYVgY= Received: by 10.70.9.4 with SMTP id 4mr24679201wxi.1167183465896; Tue, 26 Dec 2006 17:37:45 -0800 (PST) Received: from enterprise.flameeyes.is-a-geek.org ( [151.56.70.52]) by mx.google.com with ESMTP id h7sm20367206wxd.2006.12.26.17.37.44; Tue, 26 Dec 2006 17:37:45 -0800 (PST) From: "Diego 'Flameeyes' =?iso-8859-1?q?Petten=F2?=" To: xfs@oss.sgi.com Subject: Correction: acl patch (to leave the .la file to libtool) for 2.2.39 Date: Wed, 27 Dec 2006 02:37:28 +0100 User-Agent: KMail/1.9.5 X-Face: +=-v@W}H`=.Bn2t&97Un7{[.c0aP0"8)JI?7Z?E>l>ZNY|,mL\3bs xW#jRz|Va\@NIS3-'W[F.^YLqK=rS:D*Ke`Y5giI@$(xIBQ<0i740;wuI{lYd>>eFVDuAr ;r[*~/zd`4dEI MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2574674.mR8yEfx0HH"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612270237.28711@enterprise.flameeyes.is-a-geek.org> X-archive-position: 10139 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: flameeyes@gentoo.org Precedence: bulk X-list: xfs Content-Length: 2151 Lines: 68 --nextPart2574674.mR8yEfx0HH Content-Type: multipart/mixed; boundary="Boundary-01=_Y5ckFrcZGtFQ3i0" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_Y5ckFrcZGtFQ3i0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I've erroneously sent the patch for an old version of acl, I'm attaching th= e=20 correct one for 2.2.39. --=20 Diego "Flameeyes" Petten=F2 - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... --Boundary-01=_Y5ckFrcZGtFQ3i0 Content-Type: text/x-diff; charset="us-ascii"; name="acl-2.2.39-leave-las-to-libtool.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="acl-2.2.39-leave-las-to-libtool.patch" Index: acl-2.2.39/m4/package_attrdev.m4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- acl-2.2.39.orig/m4/package_attrdev.m4 +++ acl-2.2.39/m4/package_attrdev.m4 @@ -48,8 +48,6 @@ AC_DEFUN([AC_PACKAGE_NEED_GETXATTR_LIBAT libattr=3D"-lattr" test -f `pwd`/../attr/libattr/libattr.la && \ libattr=3D"`pwd`/../attr/libattr/libattr.la" - test -f ${libexecdir}${libdirsuffix}/libattr.la && \ - libattr=3D"${libexecdir}${libdirsuffix}/libattr.la" AC_SUBST(libattr) ]) =20 @@ -64,8 +62,6 @@ AC_DEFUN([AC_PACKAGE_NEED_ATTRGET_LIBATT libattr=3D"-lattr" test -f `pwd`/../attr/libattr/libattr.la && \ libattr=3D"`pwd`/../attr/libattr/libattr.la" - test -f ${libexecdir}${libdirsuffix}/libattr.la && \ - libattr=3D"${libexecdir}${libdirsuffix}/libattr.la" AC_SUBST(libattr) ]) =20 --Boundary-01=_Y5ckFrcZGtFQ3i0-- --nextPart2574674.mR8yEfx0HH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFkc5Ye2h1+2mHVWMRAkCnAJ4k3O2JrnPAwhRcyiO85Fum7xEVqQCglKLs VTNZ3fcAeKtrJxSWGgIgZS0= =YFBW -----END PGP SIGNATURE----- --nextPart2574674.mR8yEfx0HH-- From owner-xfs@oss.sgi.com Tue Dec 26 17:41:03 2006 Received: with ECARTIS (v1.0.0; list xfs); Tue, 26 Dec 2006 17:41:07 -0800 (PST) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBR1f1qw006333 for ; Tue, 26 Dec 2006 17:41:03 -0800 Received: by wx-out-0506.google.com with SMTP id t4so3838899wxc for ; Tue, 26 Dec 2006 17:40:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:x-face:mime-version:content-type:content-transfer-encoding:message-id:sender; b=L+f2Yj/NZ0Nq/VkxGwJByMrpu7vDuotGyjEtEOmUNwX8zGBPpAOSeZPPaG352JZ3qCTnrmO+HGGhFLs4jgz+1yU1gIZCduO4B7EQE2LdpDrH7bnQkMdXmGDdq7GStEZXtn5CqO0TbqD+lNVbUvXwz+lGpPf0oyvJ47COKxA2bL4= Received: by 10.90.31.19 with SMTP id e19mr11300397age.1167181971397; Tue, 26 Dec 2006 17:12:51 -0800 (PST) Received: from enterprise.flameeyes.is-a-geek.org ( [151.56.70.52]) by mx.google.com with ESMTP id 38sm19718847aga.2006.12.26.17.12.49; Tue, 26 Dec 2006 17:12:50 -0800 (PST) From: "Diego 'Flameeyes' =?iso-8859-1?q?Petten=F2?=" To: xfs@oss.sgi.com Subject: Patch for attr and acl to correctly use libtool while crosscompiling Date: Wed, 27 Dec 2006 02:12:31 +0100 User-Agent: KMail/1.9.5 X-Face: +=-v@W}H`=.Bn2t&97Un7{[.c0aP0"8)JI?7Z?E>l>ZNY|,mL\3bs xW#jRz|Va\@NIS3-'W[F.^YLqK=rS:D*Ke`Y5giI@$(xIBQ<0i740;wuI{lYd>>eFVDuAr ;r[*~/zd`4dEI MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3264982.kTH0vska8r"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612270212.40922@enterprise.flameeyes.is-a-geek.org> X-archive-position: 10140 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: flameeyes@gentoo.org Precedence: bulk X-list: xfs Content-Length: 4827 Lines: 143 --nextPart3264982.kTH0vska8r Content-Type: multipart/mixed; boundary="Boundary-01=_AickF+D9x3X3lXi" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_AickF+D9x3X3lXi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I'm attaching a patch, that applies to attr as well as acl, and allows to= =20 cross-compile attr and acl, by correctly using GNU libtool (building a loca= l=20 copy of it) rather than abusing the system one (that might not be suited fo= r=20 the crosscompile target). Basically, the search for libtool is demanded to AC_PROG_LIBTOOL macro as= =20 needed (that requires top_builddir being expanded), and AC_PROG_CC has to b= e=20 called (or the wrong compiler would be used and libtool would bail out on= =20 itself at final link). For acl there's also an extra patch, that removes the use=20 of /usr/lib/libattr.la if found, this because /usr/lib/libattr.la might not= =20 be compiled for the platform you're building for; just leave -lattr to=20 libtool to expand to the correct .la file (unless building inline in the sa= me=20 directory). With these patches applied, crosscompiling acl and attr is a piece of cacke. HTH, --=20 Diego "Flameeyes" Petten=F2 - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, Sound, ALSA, PAM, KDE, CJK, Ruby ... --Boundary-01=_AickF+D9x3X3lXi Content-Type: text/x-diff; charset="iso-8859-1"; name="attr-2.4.32-libtool.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="attr-2.4.32-libtool.patch" Index: attr-2.4.32/m4/package_utilies.m4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- attr-2.4.32.orig/m4/package_utilies.m4 +++ attr-2.4.32/m4/package_utilies.m4 @@ -32,15 +32,7 @@ AC_DEFUN([AC_PACKAGE_UTILITIES], AC_SUBST(make) AC_PACKAGE_NEED_UTILITY($1, "$make", make, [GNU make]) =20 - if test -z "$LIBTOOL"; then - AC_PATH_PROG(LIBTOOL, glibtool,, /usr/bin) - fi - if test -z "$LIBTOOL"; then - AC_PATH_PROG(LIBTOOL, libtool,, /usr/bin:/usr/local/bin:/usr/freeware/bin) - fi - libtool=3D$LIBTOOL - AC_SUBST(libtool) - AC_PACKAGE_NEED_UTILITY($1, "$libtool", libtool, [GNU libtool]) + AC_PROG_LIBTOOL =20 if test -z "$TAR"; then AC_PATH_PROG(TAR, tar,, /usr/freeware/bin:/bin:/usr/local/bin:/usr= /bin) Index: attr-2.4.32/include/builddefs.in =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- attr-2.4.32.orig/include/builddefs.in +++ attr-2.4.32/include/builddefs.in @@ -17,6 +17,7 @@ LIBMISC =3D $(TOPDIR)/libmisc/libmisc.la =20 prefix =3D @prefix@ exec_prefix =3D @exec_prefix@ +top_builddir =3D @top_builddir@ =20 PKG_NAME =3D @pkg_name@ PKG_USER =3D @pkg_user@ Index: attr-2.4.32/m4/package_globals.m4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- attr-2.4.32.orig/m4/package_globals.m4 +++ attr-2.4.32/m4/package_globals.m4 @@ -8,6 +8,8 @@ AC_DEFUN([AC_PACKAGE_GLOBALS], [ pkg_name=3D"$1" AC_SUBST(pkg_name) =20 + AC_PROG_CC + . ./VERSION pkg_version=3D${PKG_MAJOR}.${PKG_MINOR}.${PKG_REVISION} AC_SUBST(pkg_version) --Boundary-01=_AickF+D9x3X3lXi Content-Type: text/x-diff; charset="iso-8859-1"; name="acl-2.2.34-leave-las-to-libtool.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="acl-2.2.34-leave-las-to-libtool.patch" Index: acl-2.2.34/m4/package_attrdev.m4 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- acl-2.2.34.orig/m4/package_attrdev.m4 +++ acl-2.2.34/m4/package_attrdev.m4 @@ -43,7 +43,6 @@ AC_DEFUN([AC_PACKAGE_NEED_GETXATTR_LIBAT libattr=3D"-lattr" test -f `pwd`/../attr/libattr/libattr.la && \ libattr=3D"`pwd`/../attr/libattr/libattr.la" - test -f /usr/lib/libattr.la && libattr=3D"/usr/lib/libattr.la" AC_SUBST(libattr) ]) =20 --Boundary-01=_AickF+D9x3X3lXi-- --nextPart3264982.kTH0vska8r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBFkciIe2h1+2mHVWMRAh0QAKC0leWqxQLLeQV+c9H9sh13sCXlvACeNQ1j c+sXG2hwzFP7LD/W31+HgXo= =VJqo -----END PGP SIGNATURE----- --nextPart3264982.kTH0vska8r-- From owner-xfs@oss.sgi.com Wed Dec 27 05:02:18 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 27 Dec 2006 05:02:22 -0800 (PST) Received: from netcenter.hu (ns.netcenter.hu [195.228.254.57]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBRD2Fqw018793 for ; Wed, 27 Dec 2006 05:02:17 -0800 Received: from dcccs (dsl5401D0F5.pool.t-online.hu [84.1.208.245]) by netcenter.hu (8.13.4/8.12.8) with SMTP id kBRCwedZ031744; Wed, 27 Dec 2006 13:58:41 +0100 Message-ID: <041601c729b6$f81e4af0$0400a8c0@dcccs> From: =?ISO-8859-1?Q?Haar_J=E1nos?= To: "David Chinner" Cc: , , References: <00ab01c71e53$942af2f0$0400a8c0@dcccs> <000d01c72127$3d7509b0$0400a8c0@dcccs> <20061217224457.GN33919298@melbourne.sgi.com> <026501c72237$0464f7a0$0400a8c0@dcccs> <20061218062444.GH44411608@melbourne.sgi.com> <027b01c7227d$0e26d1f0$0400a8c0@dcccs> <20061218223637.GP44411608@melbourne.sgi.com> <001a01c722fd$df5ca710$0400a8c0@dcccs> <20061219025229.GT33919298@melbourne.sgi.com> <20061219044700.GW33919298@melbourne.sgi.com> Subject: Re: xfslogd-spinlock bug? Date: Wed, 27 Dec 2006 13:58:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-archive-position: 10141 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: djani22@netcenter.hu Precedence: bulk X-list: xfs Content-Length: 6668 Lines: 151 Hello, ----- Original Message ----- From: "David Chinner" To: "David Chinner" Cc: "Haar János" ; ; Sent: Tuesday, December 19, 2006 5:47 AM Subject: Re: xfslogd-spinlock bug? > On Tue, Dec 19, 2006 at 01:52:29PM +1100, David Chinner wrote: > > On Tue, Dec 19, 2006 at 12:39:46AM +0100, Haar János wrote: > > > From: "David Chinner" > > > > #define POISON_FREE 0x6b > > > > > > > > Can you confirm that you are running with CONFIG_DEBUG_SLAB=y? > > > > > > Yes, i build with this option enabled. > > ...... > > > FWIW, I've run XFSQA twice now on a scsi disk with slab debuggin turned > > on and I haven't seen this problem. I'm not sure how to track down > > the source of the problem without a test case, but as a quick test, can > > you try the following patch? > > Third try an I got a crash on a poisoned object: > > [1]kdb> md8c40 e00000300d7d5100 > 0xe00000300d7d5100 000000005a2cf071 0000000000000000 q.,Z............ > 0xe00000300d7d5110 000000005a2cf071 6b6b6b6b6b6b6b6b q.,Z....kkkkkkkk > 0xe00000300d7d5120 e0000039eb7b6320 6b6b6b6b6b6b6b6b c{.9...kkkkkkkk > 0xe00000300d7d5130 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk > 0xe00000300d7d5140 6b6b6b6f6b6b6b6b 6b6b6b6b6b6b6b6b kkkkokkkkkkkkkkk > 0xe00000300d7d5150 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk > 0xe00000300d7d5160 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk > 0xe00000300d7d5170 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk > 0xe00000300d7d5180 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk > 0xe00000300d7d5190 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk > 0xe00000300d7d51a0 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk > 0xe00000300d7d51b0 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk > 0xe00000300d7d51c0 6b6b6b6b6b6b6b6b 6b6b6b6b6b6b6b6b kkkkkkkkkkkkkkkk > 0xe00000300d7d51d0 6b6b6b6b6b6b6b6b a56b6b6b6b6b6b6b kkkkkkkkkkkkkkk. > 0xe00000300d7d51e0 000000005a2cf071 a000000100468c30 q.,Z....0.F..... > [1]kdb> mds 0xe00000300d7d51e0 > 0xe00000300d7d51e0 5a2cf071 q.,Z.... > 0xe00000300d7d51e8 a000000100468c30 xfs_inode_item_destroy+0x30 > > So the use-after-free here is on an inode item. You're tripping > over a buffer item. > > Unfortunately, it is not the same problem - the problem I've just > hit is to do with a QA test that does a forced shutdown on an active > filesystem, and: > > [1]kdb> xmount 0xe00000304393e238 > ..... > flags 0x440010 > > The filesystem was being shutdown so xfs_inode_item_destroy() just > frees the inode log item without removing it from the AIL. I'll fix that, > and see if i have any luck.... > > So I'd still try that patch i sent in the previous email... I still using the patch, but didnt shows any messages at this point. I'v got 3 crash/reboot, but 2 causes nbd disconneted, and this one: Dec 27 13:41:29 dy-base BUG: warning at kernel/mutex.c:220/__mutex_unlock_common_slowpath() Dec 27 13:41:29 dy-base Unable to handle kernel paging request at 0000000066604480 RIP: Dec 27 13:41:29 dy-base [] resched_task+0x12/0x64 Dec 27 13:41:29 dy-base PGD 115246067 PUD 0 Dec 27 13:41:29 dy-base Oops: 0000 [1] SMP Dec 27 13:41:29 dy-base CPU 1 Dec 27 13:41:29 dy-base Modules linked in: nbd rd netconsole e1000 video Dec 27 13:41:29 dy-base Pid: 4069, comm: httpd Not tainted 2.6.19 #3 Dec 27 13:41:29 dy-base RIP: 0010:[] [] resched_task+0x12/0x64 Dec 27 13:41:29 dy-base RSP: 0018:ffff810105c01b78 EFLAGS: 00010083 Dec 27 13:41:29 dy-base RAX: ffffffff807d5800 RBX: 00001749fd97c214 RCX: ffff81001cbd0000 Dec 27 13:41:29 dy-base RDX: 000000001cbd0048 RSI: ffff810005834068 RDI: ffff8101047bf040 Dec 27 13:41:29 dy-base RBP: ffff810105c01b78 R08: 0000000000000001 R09: 0000000000000000 Dec 27 13:41:29 dy-base R10: 0000000000000057 R11: ffff81000583cd80 R12: ffff810116693140 Dec 27 13:41:29 dy-base R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 Dec 27 13:41:29 dy-base FS: 00002ba3c1ad07d0(0000) GS:ffff81011fc769c8(0000) knlGS:0000000000000000 Dec 27 13:41:29 dy-base CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Dec 27 13:41:29 dy-base CR2: 0000000066604480 CR3: 0000000118196000 CR4: 00000000000006e0 Dec 27 13:41:29 dy-base Process httpd (pid: 4069, threadinfo ffff810105c00000, task ffff8101166e1040) Dec 27 13:41:29 dy-base Stack: ffff810105c01bf8 ffffffff80223f37 ffff810002996a00 0000000002cba600 Dec 27 13:41:29 dy-base 000000000000000f 0000000000000001 ffff810005833700 0000000100000000 Dec 27 13:41:29 dy-base 0000000000000005 0000000000000296 ffff810105c01bd8 ffff810117fef690 Dec 27 13:41:29 dy-base Call Trace: Dec 27 13:41:29 dy-base [] try_to_wake_up+0x3a7/0x3dc Dec 27 13:41:29 dy-base [] wake_up_process+0x10/0x12 Dec 27 13:41:29 dy-base [] xfsbufd_wakeup+0x34/0x61 Dec 27 13:41:29 dy-base [] shrink_slab+0x64/0x163 Dec 27 13:41:29 dy-base [] try_to_free_pages+0x19c/0x289 Dec 27 13:41:29 dy-base [] __alloc_pages+0x1b8/0x2c0 Dec 27 13:41:29 dy-base [] anon_vma_prepare+0x29/0xf1 Dec 27 13:41:29 dy-base [] __handle_mm_fault+0x496/0x9e3 Dec 27 13:41:29 dy-base [] _spin_unlock+0x9/0xb Dec 27 13:41:29 dy-base [] do_page_fault+0x418/0x7b6 Dec 27 13:41:29 dy-base [] __switch_to+0x280/0x28f Dec 27 13:41:29 dy-base [] _spin_unlock_irq+0x9/0xc Dec 27 13:41:29 dy-base [] thread_return+0x5e/0xf7 Dec 27 13:41:29 dy-base [] error_exit+0x0/0x84 Dec 27 13:41:29 dy-base Dec 27 13:41:29 dy-base Dec 27 13:41:29 dy-base Code: 48 8b 14 d5 40 42 78 80 48 03 42 08 8b 00 85 c0 7e 0a 0f 0b Dec 27 13:41:29 dy-base RIP [] resched_task+0x12/0x64 Dec 27 13:41:29 dy-base RSP Dec 27 13:41:29 dy-base CR2: 0000000066604480 Dec 27 13:41:29 dy-base <0>Kernel panic - not syncing: Fatal exception Dec 27 13:41:29 dy-base Dec 27 13:41:29 dy-base Rebooting in 5 seconds.. I found one bug on my apache config, and i think, the test case is changed. :-( Before the config is fixed, some users can stress the xfs source device readahead, and can periodically overload the system, with this action. I think, the original bug only comes on the highly overloaded system, and about readahead+buffering/caching. Thanks, Janos > > Cheers, > > Dave. > -- > Dave Chinner > Principal Engineer > SGI Australian Software Group From owner-xfs@oss.sgi.com Wed Dec 27 07:42:22 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 27 Dec 2006 07:42:30 -0800 (PST) Received: from sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBRFgKqw002977 for ; Wed, 27 Dec 2006 07:42:22 -0800 Received: from [192.168.254.1] (dsl-dynamic-209-50-27-170.inebraska.com [209.50.27.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 9EBA918011EB7; Wed, 27 Dec 2006 09:41:26 -0600 (CST) Message-ID: <4592942C.5000306@sandeen.net> Date: Wed, 27 Dec 2006 09:41:32 -0600 From: Eric Sandeen User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: fdegrassi CC: linux-xfs@oss.sgi.com Subject: Re: Possible performance problem introduced between kernel 2.6.15 and 2.6.17 on xfs code References: <458D4845.2010803@emaze.net> <458D4EEB.3060501@sandeen.net> <458DCB8D.3040804@emaze.net> In-Reply-To: <458DCB8D.3040804@emaze.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 10143 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Content-Length: 752 Lines: 20 fdegrassi wrote: > The specific problem is related to gnome point-n-click only. > Anyway, I could be wrong, but i don't think it is a bug in gnome because: > 1. it affects specifically local XFS filesystems only > 2. the problem is not present on kernel 2.6.15 (I tested 2.6.17 and > 2.6.15, both on ubuntu 6.10) > 3. the problem does not manifest if i disable the call to > gnome_vfs_forget_cache, that, for what i understand, simply calls > fadvice POSIX_FADV_DONTNEED. > > More info can be found on gnome bugzilla entry. > Francesco Degrassi > Thanks. I didn't mean to suggest that it was necessarily a gnome bug, just wanted to narrow down the problem. Do you have any idea if other filesystems on 2.6.17 also show this slowdown? -Eric From owner-xfs@oss.sgi.com Wed Dec 27 09:58:16 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 27 Dec 2006 09:58:21 -0800 (PST) Received: from deflector.emaze.net (deflector.emaze.net [213.178.220.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBRHwEqw021218 for ; Wed, 27 Dec 2006 09:58:16 -0800 Received: from localhost (localhost [127.0.0.1]) by deflector.emaze.net (Postfix) with ESMTP id D7129F28195; Wed, 27 Dec 2006 18:55:54 +0100 (CET) Received: from deflector.emaze.net ([127.0.0.1]) by localhost (deflector [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10939-02; Wed, 27 Dec 2006 18:55:54 +0100 (CET) Received: from [192.168.1.197] (internal.emaze.net [192.168.150.2]) by deflector.emaze.net (Postfix) with ESMTP id 23F75F2818C; Wed, 27 Dec 2006 18:55:54 +0100 (CET) Message-ID: <4592B581.7080806@emaze.net> Date: Wed, 27 Dec 2006 19:03:45 +0100 From: Francesco Degrassi User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: Possible performance problem introduced between kernel 2.6.15 and 2.6.17 on xfs code References: <458D4845.2010803@emaze.net> <458D4EEB.3060501@sandeen.net> <458DCB8D.3040804@emaze.net> <4592942C.5000306@sandeen.net> In-Reply-To: <4592942C.5000306@sandeen.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10144 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: francesco.degrassi@emaze.net Precedence: bulk X-list: xfs Content-Length: 1861 Lines: 57 I tried ext2, ext3, jfs, reiser3, vfat and the problem does not show up. Anyway i discovered that if i create a regular file in an XFS partition, create an XFS filesystem on it as if it was a regular block device, and mount it with the loop device, the problem does NOT manifest. So it seems to affect XFS filesystems on regular block devices only ? I'm confused. ____________EXAMPLE________________ root@francesco:/tmp$ mount | grep tmp /dev/sda7 on /tmp type xfs (rw) root@francesco:/tmp$ dd if=/dev/zero of=bdev bs=1024 count=200000 root@francesco:/tmp$ mkfs.xfs -f bdev root@francesco:/tmp$ mkdir mpoint root@francesco:/tmp$ mount -o loop bdev mpoint/ root@francesco:/tmp$ time gnomevfs-copy \ /home/fdegrassi/Desktop/downloads/systemrescuecd-x86-1.2.18.iso mpoint/ real 0m3.998s user 0m0.080s sys 0m1.292s root@francesco:/tmp$ time gnomevfs-copy \ /home/fdegrassi/Desktop/downloads/systemrescuecd-x86-1.2.18.iso /tmp real 2m55.448s user 0m0.100s sys 0m1.984s ________________________END_____________________ Thanks for your time, Eric. Francesco Degrassi Eric Sandeen wrote: > fdegrassi wrote: >> The specific problem is related to gnome point-n-click only. >> Anyway, I could be wrong, but i don't think it is a bug in gnome because: >> 1. it affects specifically local XFS filesystems only >> 2. the problem is not present on kernel 2.6.15 (I tested 2.6.17 and >> 2.6.15, both on ubuntu 6.10) >> 3. the problem does not manifest if i disable the call to >> gnome_vfs_forget_cache, that, for what i understand, simply calls >> fadvice POSIX_FADV_DONTNEED. >> >> More info can be found on gnome bugzilla entry. >> Francesco Degrassi >> > > Thanks. I didn't mean to suggest that it was necessarily a gnome bug, > just wanted to narrow down the problem. Do you have any idea if other > filesystems on 2.6.17 also show this slowdown? > > -Eric From owner-xfs@oss.sgi.com Wed Dec 27 10:06:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Wed, 27 Dec 2006 10:06:49 -0800 (PST) Received: from astra.simleu.ro (astra.simleu.ro [80.97.18.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBRI6fqw022684 for ; Wed, 27 Dec 2006 10:06:43 -0800 Received: from teal.hq.k1024.org (84-75-114-110.dclient.hispeed.ch [84.75.114.110]) by astra.simleu.ro (Postfix) with ESMTP id 04B0C59; Wed, 27 Dec 2006 20:05:46 +0200 (EET) Received: by teal.hq.k1024.org (Postfix, from userid 4004) id 4D19940BE41; Wed, 27 Dec 2006 19:05:42 +0100 (CET) Date: Wed, 27 Dec 2006 19:05:42 +0100 From: Iustin Pop To: Francesco Degrassi Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Possible performance problem introduced between kernel 2.6.15 and 2.6.17 on xfs code Message-ID: <20061227180542.GA6888@teal.hq.k1024.org> Mail-Followup-To: Francesco Degrassi , Eric Sandeen , linux-xfs@oss.sgi.com References: <458D4845.2010803@emaze.net> <458D4EEB.3060501@sandeen.net> <458DCB8D.3040804@emaze.net> <4592942C.5000306@sandeen.net> <4592B581.7080806@emaze.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4592B581.7080806@emaze.net> X-Linux: This message was written on Linux X-Header: /usr/include gives great headers User-Agent: Mutt/1.5.13 (2006-08-11) X-archive-position: 10145 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: iusty@k1024.org Precedence: bulk X-list: xfs Content-Length: 874 Lines: 18 On Wed, Dec 27, 2006 at 07:03:45PM +0100, Francesco Degrassi wrote: > I tried ext2, ext3, jfs, reiser3, vfat and the problem does not show up. > Anyway i discovered that if i create a regular file in an XFS partition, > create an XFS filesystem on it as if it was a regular block device, and > mount it with the loop device, the problem does NOT manifest. > So it seems to affect XFS filesystems on regular block devices only ? > I'm confused. This is probably not related, but I remember that barriers were added sometime between 2.6.15 and 2.6.17 and probably barriers are not enabled on a loop filesystem. Maybe the gnome vfs thing does some sync which force flushes or such. I'm no expert, just guessing. Just to invalidate this (probably wrong) guess, could you try to mount /tmp with "-o nobarrier" and re-test? Iustin, who wishes md raid1 would support barriers. From owner-xfs@oss.sgi.com Thu Dec 28 01:51:21 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 28 Dec 2006 01:51:28 -0800 (PST) Received: from deflector.emaze.net (deflector.emaze.net [213.178.220.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBS9pJqw024375 for ; Thu, 28 Dec 2006 01:51:21 -0800 Received: from localhost (localhost [127.0.0.1]) by deflector.emaze.net (Postfix) with ESMTP id BAF81F28152; Thu, 28 Dec 2006 10:49:00 +0100 (CET) Received: from deflector.emaze.net ([127.0.0.1]) by localhost (deflector [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17058-05; Thu, 28 Dec 2006 10:49:00 +0100 (CET) Received: from [192.168.1.197] (internal.emaze.net [192.168.150.2]) by deflector.emaze.net (Postfix) with ESMTP id 6F93EF2814B; Thu, 28 Dec 2006 10:49:00 +0100 (CET) Message-ID: <459394EA.3000304@emaze.net> Date: Thu, 28 Dec 2006 10:56:58 +0100 From: Francesco Degrassi User-Agent: Thunderbird 1.5.0.8 (X11/20061115) MIME-Version: 1.0 To: iusty@k1024.org CC: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Possible performance problem introduced between kernel 2.6.15 and 2.6.17 on xfs code References: <458D4845.2010803@emaze.net> <458D4EEB.3060501@sandeen.net> <458DCB8D.3040804@emaze.net> <4592942C.5000306@sandeen.net> <4592B581.7080806@emaze.net> <20061227180542.GA6888@teal.hq.k1024.org> In-Reply-To: <20061227180542.GA6888@teal.hq.k1024.org> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10148 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: francesco.degrassi@emaze.net Precedence: bulk X-list: xfs Content-Length: 1341 Lines: 32 Hi Iustin, i tried and it and indeed the performance problem does not manifest if i mount the xfs filesystem with the -o nobarrier option. Seems like we are a little bit closer to the real problem now. The code in gnomevfs-copy calls fadvice POSIX_FADV_DONTNEED (in gnome_vfs_forget_cache) and disabling this behaviour gets back normal performance, so it has something to do with that. Thanks for your help Francesco Iustin Pop wrote: > On Wed, Dec 27, 2006 at 07:03:45PM +0100, Francesco Degrassi wrote: >> I tried ext2, ext3, jfs, reiser3, vfat and the problem does not show up. >> Anyway i discovered that if i create a regular file in an XFS partition, >> create an XFS filesystem on it as if it was a regular block device, and >> mount it with the loop device, the problem does NOT manifest. >> So it seems to affect XFS filesystems on regular block devices only ? >> I'm confused. > > This is probably not related, but I remember that barriers were added > sometime between 2.6.15 and 2.6.17 and probably barriers are not enabled > on a loop filesystem. Maybe the gnome vfs thing does some sync which > force flushes or such. I'm no expert, just guessing. > > Just to invalidate this (probably wrong) guess, could you try to mount > /tmp with "-o nobarrier" and re-test? > > Iustin, who wishes md raid1 would support barriers. From owner-xfs@oss.sgi.com Thu Dec 28 02:42:44 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 28 Dec 2006 02:42:49 -0800 (PST) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id kBSAgeqw029912 for ; Thu, 28 Dec 2006 02:42:42 -0800 Received: from [134.15.251.1] ([134.15.251.1]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA18612; Thu, 28 Dec 2006 21:21:53 +1100 Message-ID: <45939ABD.6010600@melbourne.sgi.com> Date: Thu, 28 Dec 2006 21:21:49 +1100 From: David Chatterton Reply-To: chatz@melbourne.sgi.com Organization: SGI User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Ying-Hung Chen CC: linux-xfs@oss.sgi.com Subject: Re: xfs_repair xfsprogs version > 2.8.11 References: <458E643D.3090008@yingternet.com> <458FA0F8.1020107@yingternet.com> In-Reply-To: <458FA0F8.1020107@yingternet.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10149 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: chatz@melbourne.sgi.com Precedence: bulk X-list: xfs Content-Length: 1732 Lines: 74 Ying-Hung, Can you please provide some info on your configuration? Obviously we are not seeing this problem in our own tests and reproducing this will help to resolve it. Thanks, David Ying-Hung Chen wrote: > Hi there, > > actually, i have trace the code in to xfs_repair/threads.c (taken from > 2.8.18) > > void > thread_init(void) > { > .... > if ((status = pthread_attr_getstacksize(&attr, &stacksize)) != 0) > do_error(_("status from pthread_attr_getstacksize: %d"), > status); > > stacksize *= 4; > > if ((status = pthread_attr_setstacksize(&attr, stacksize)) != 0) > do_error(_("status from pthread_attr_setstacksize: %d"), > status); > .... > } > > the repair program dies in pthread_attr_setstacksize(&attr, stacksize)). > is there any reason why the program is trying to set the stacksize into > 4 times the current size? > > just for testing purposes, I remove the stacksize *= 4; the xfs_repair > seems to 'work', at least from user's point of view. > > I have tested with x86 32bits machines with 2.4 and 2.6 kernels, they > both yield with the same results, > > Thanks, > > -Ying > > Ying-Hung Chen wrote: >> Hi there, >> >> I found that xfs_repair always returns the following message with the >> xfsprogs version > 2.8.11 >> >> [root@yroro i586]# xfs_repair /dev/hdb1 >> >> fatal error -- status from pthread_attr_setstacksize: 22 >> >> from the ChangeLog, seems like there is some internal changes with >> threads starting 2.8.11 .. the xfs_repair works for me up to 2.8.11, it >> fails to work on 2.8.16 and 2.8.18, >> >> how do I work around this problem? >> >> Thanks, >> >> -Ying >> > -- David Chatterton XFS Engineering Manager SGI Australia From owner-xfs@oss.sgi.com Thu Dec 28 05:42:59 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 28 Dec 2006 05:43:05 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBSDglqw019839 for ; Thu, 28 Dec 2006 05:42:50 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id DEA7A616D16C; Thu, 28 Dec 2006 08:41:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id D2D2216134E33; Thu, 28 Dec 2006 08:41:55 -0500 (EST) Date: Thu, 28 Dec 2006 08:41:55 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34.internal.lan To: linux-kernel@vger.kernel.org cc: xfs@oss.sgi.com Subject: Re: Kernel 2.6.19: Kernel Panic! XFS / UDEV Issue? In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10151 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs Content-Length: 77929 Lines: 1715 Any idea what happened here? On Tue, 26 Dec 2006, Justin Piszcz wrote: > I use netconsole on all my machines and it caught the crash, I was not > doing anything special, just rebooted my machine and when it was booting, > this happened: > > Looks like an XFS problem? > > System Events > =-=-=-=-=-=-= > Dec 26 15:59:37 box [ 0.000000] BIOS-provided physical RAM map: > Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) > Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) > Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) > Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 0000000000100000 - 000000007fff0000 (usable) > Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 000000007fff0000 - 000000007fff3000 (ACPI NVS) > Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 000000007fff3000 - 0000000080000000 (ACPI data) > Dec 26 15:59:37 box [ 0.000000] BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) > Dec 26 15:59:37 box [ 0.000000] 1151MB HIGHMEM available. > Dec 26 15:59:37 box [ 0.000000] 896MB LOWMEM available. > Dec 26 15:59:37 box [ 0.000000] found SMP MP-table at 000f5d10 > Dec 26 15:59:37 box [ 0.000000] Zone PFN ranges: > Dec 26 15:59:37 box [ 0.000000] DMA 0 -> 4096 > Dec 26 15:59:37 box [ 0.000000] Normal 4096 -> 229376 > Dec 26 15:59:37 box [ 0.000000] HighMem 229376 -> 524272 > Dec 26 15:59:37 box [ 0.000000] early_node_map[1] active PFN ranges > Dec 26 15:59:37 box [ 0.000000] 0: 0 -> 524272 > Dec 26 15:59:37 box [ 0.000000] DMI 2.2 present. > Dec 26 15:59:37 box [ 0.000000] ACPI: PM-Timer IO Port: 0x408 > Dec 26 15:59:37 box [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > Dec 26 15:59:37 box [ 0.000000] Processor #0 15:2 APIC version 20 > Dec 26 15:59:37 box [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) > Dec 26 15:59:37 box [ 0.000000] Processor #1 15:2 APIC version 20 > Dec 26 15:59:37 box [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) > Dec 26 15:59:37 box [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) > Dec 26 15:59:37 box [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) > Dec 26 15:59:37 box [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > Dec 26 15:59:37 box [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > Dec 26 15:59:37 box [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > Dec 26 15:59:37 box [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs > Dec 26 15:59:37 box [ 0.000000] Using ACPI (MADT) for SMP configuration information > Dec 26 15:59:37 box [ 0.000000] Allocating PCI resources starting at 88000000 (gap: 80000000:7ec00000) > Dec 26 15:59:37 box [ 0.000000] Detected 2606.071 MHz processor. > Dec 26 15:59:37 box [ 22.359952] Built 1 zonelists. Total pages: 520177 > Dec 26 15:59:37 box [ 22.359955] Kernel command line: auto BOOT_IMAGE=2.6.19-2 ro root=802 netconsole=4444@192.168.168.1/eth0,514@192.168.0.254/00:07:C9:55:47:AB nmi_watchdog=1 > Dec 26 15:59:37 box [ 22.359995] netconsole: local port 4444 > Dec 26 15:59:37 box [ 22.359998] netconsole: local IP 192.168.168.1 > Dec 26 15:59:37 box [ 22.360000] netconsole: interface eth0 > Dec 26 15:59:37 box [ 22.360002] netconsole: remote port 514 > Dec 26 15:59:37 box [ 22.360004] netconsole: remote IP 192.168.0.254 > Dec 26 15:59:37 box [ 22.360008] netconsole: remote ethernet address 00:07:e9:29:37:db > Dec 26 15:59:37 box [ 22.360179] Enabling fast FPU save and restore... done. > Dec 26 15:59:37 box [ 22.360182] Enabling unmasked SIMD FPU exception support... done. > Dec 26 15:59:37 box [ 22.360186] Initializing CPU#0 > Dec 26 15:59:37 box [ 22.360251] PID hash table entries: 4096 (order: 12, 16384 bytes) > Dec 26 15:59:37 box [ 22.361425] Console: colour VGA+ 80x25 > Dec 26 15:59:37 box [ 22.364157] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) > Dec 26 15:59:37 box [ 22.364658] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) > Dec 26 15:59:37 box [ 22.463391] Memory: 2074188k/2097088k available (3017k kernel code, 21684k reserved, 872k data, 216k init, 1179584k highmem) > Dec 26 15:59:37 box [ 22.463467] virtual kernel memory layout: > Dec 26 15:59:37 box [ 22.463468] fixmap : 0xfff9d000 - 0xfffff000 ( 392 kB) > Dec 26 15:59:37 box [ 22.463469] pkmap : 0xff800000 - 0xffc00000 (4096 kB) > Dec 26 15:59:37 box [ 22.463470] vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB) > Dec 26 15:59:37 box [ 22.463471] lowmem : 0xc0000000 - 0xf8000000 ( 896 MB) > Dec 26 15:59:37 box [ 22.463472] .init : 0xc04d3000 - 0xc0509000 ( 216 kB) > Dec 26 15:59:37 box [ 22.463473] .data : 0xc03f2412 - 0xc04cc424 ( 872 kB) > Dec 26 15:59:37 box [ 22.463475] .text : 0xc0100000 - 0xc03f2412 (3017 kB) > Dec 26 15:59:37 box [ 22.463860] Checking if this processor honours the WP bit even in supervisor mode... Ok. > Dec 26 15:59:37 box [ 22.523834] Calibrating delay using timer specific routine.. 5213.93 BogoMIPS (lpj=2606966) > Dec 26 15:59:37 box [ 22.523973] Mount-cache hash table entries: 512 > Dec 26 15:59:37 box [ 22.524142] CPU: Trace cache: 12K uops, L1 D cache: 8K > Dec 26 15:59:37 box [ 22.524226] CPU: L2 cache: 512K > Dec 26 15:59:37 box [ 22.524274] CPU: Physical Processor ID: 0 > Dec 26 15:59:37 box [ 22.524343] Checking 'hlt' instruction... OK. > Dec 26 15:59:37 box [ 22.528015] Freeing SMP alternatives: 12k freed > Dec 26 15:59:37 box [ 22.528065] ACPI: Core revision 20060707 > Dec 26 15:59:37 box [ 22.547938] CPU0: Intel(R) Pentium(R) 4 CPU 2.60GHz stepping 09 > Dec 26 15:59:37 box [ 22.548078] Booting processor 1/1 eip 2000 > Dec 26 15:59:37 box [ 22.558416] Initializing CPU#1 > Dec 26 15:59:37 box [ 22.618587] Calibrating delay using timer specific routine.. 5211.07 BogoMIPS (lpj=2605538) > Dec 26 15:59:37 box [ 22.618607] CPU: Trace cache: 12K uops, L1 D cache: 8K > Dec 26 15:59:37 box [ 22.618610] CPU: L2 cache: 512K > Dec 26 15:59:37 box [ 22.618612] CPU: Physical Processor ID: 0 > Dec 26 15:59:37 box [ 22.618778] CPU1: Intel(R) Pentium(R) 4 CPU 2.60GHz stepping 09 > Dec 26 15:59:37 box [ 22.619156] Total of 2 processors activated (10425.00 BogoMIPS). > Dec 26 15:59:37 box [ 22.619333] ENABLING IO-APIC IRQs > Dec 26 15:59:37 box [ 22.619553] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1 > Dec 26 15:59:37 box [ 22.731308] checking TSC synchronization across 2 CPUs: passed. > Dec 26 15:59:37 box [ 0.000955] Brought up 2 CPUs > Dec 26 15:59:37 box [ 0.054654] migration_cost=44 > Dec 26 15:59:37 box [ 0.055223] NET: Registered protocol family 16 > Dec 26 15:59:37 box [ 0.055360] ACPI: bus type pci registered > Dec 26 15:59:37 box [ 0.067272] PCI: PCI BIOS revision 2.10 entry at 0xfb720, last bus=3 > Dec 26 15:59:37 box [ 0.067324] PCI: Using configuration type 1 > Dec 26 15:59:37 box [ 0.067372] Setting up standard PCI resources > Dec 26 15:59:37 box [ 0.078356] ACPI: Interpreter enabled > Dec 26 15:59:37 box [ 0.078409] ACPI: Using IOAPIC for interrupt routing > Dec 26 15:59:37 box [ 0.079073] ACPI: PCI Root Bridge [PCI0] (0000:00) > Dec 26 15:59:37 box [ 0.081912] PCI quirk: region 0400-047f claimed by ICH4 ACPI/GPIO/TCO > Dec 26 15:59:37 box [ 0.081966] PCI quirk: region 0480-04bf claimed by ICH4 GPIO > Dec 26 15:59:37 box [ 0.082062] PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1 > Dec 26 15:59:37 box [ 0.082778] PCI: Transparent bridge - 0000:00:1e.0 > Dec 26 15:59:37 box [ 0.096418] ACPI: PCI Interrupt Link [LNKA] (IRQs *3 4 5 7 9 10 11 12 14 15) > Dec 26 15:59:37 box [ 0.097163] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 *11 12 14 15) > Dec 26 15:59:37 box [ 0.097907] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 *10 11 12 14 15) > Dec 26 15:59:37 box [ 0.098638] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 *5 7 9 10 11 12 14 15) > Dec 26 15:59:37 box [ 0.099377] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, disabled. > Dec 26 15:59:37 box [ 0.100194] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 *9 10 11 12 14 15) > Dec 26 15:59:37 box [ 0.100934] ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 7 9 10 *11 12 14 15) > Dec 26 15:59:37 box [ 0.101665] ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 9 *10 11 12 14 15) > Dec 26 15:59:37 box [ 0.202525] ACPI: Power Resource [PFAN] (off) > Dec 26 15:59:37 box [ 0.202881] SCSI subsystem initialized > Dec 26 15:59:37 box [ 0.203088] PCI: Using ACPI for IRQ routing > Dec 26 15:59:37 box [ 0.203139] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report > Dec 26 15:59:37 box [ 0.228483] PCI: Bridge: 0000:00:01.0 > Dec 26 15:59:37 box [ 0.228533] IO window: disabled. > Dec 26 15:59:37 box [ 0.228583] MEM window: f8000000-f9ffffff > Dec 26 15:59:37 box [ 0.228634] PREFETCH window: f0000000-f7ffffff > Dec 26 15:59:37 box [ 0.228685] PCI: Bridge: 0000:00:03.0 > Dec 26 15:59:37 box [ 0.228734] IO window: a000-afff > Dec 26 15:59:37 box [ 0.228784] MEM window: fc000000-fc0fffff > Dec 26 15:59:37 box [ 0.228834] PREFETCH window: disabled. > Dec 26 15:59:37 box [ 0.228886] PCI: Bridge: 0000:00:1e.0 > Dec 26 15:59:37 box [ 0.228935] IO window: 8000-9fff > Dec 26 15:59:37 box [ 0.228985] MEM window: fa000000-fbffffff > Dec 26 15:59:37 box [ 0.229036] PREFETCH window: 88000000-880fffff > Dec 26 15:59:37 box [ 0.229138] NET: Registered protocol family 2 > Dec 26 15:59:37 box [ 0.240374] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) > Dec 26 15:59:37 box [ 0.240578] TCP established hash table entries: 131072 (order: 8, 1572864 bytes) > Dec 26 15:59:37 box [ 0.241573] TCP bind hash table entries: 65536 (order: 7, 786432 bytes) > Dec 26 15:59:37 box [ 0.242257] TCP: Hash tables configured (established 131072 bind 65536) > Dec 26 15:59:37 box [ 0.242312] TCP reno registered > Dec 26 15:59:37 box [ 0.242860] highmem bounce pool size: 64 pages > Dec 26 15:59:37 box [ 0.243086] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). > Dec 26 15:59:37 box [ 0.243489] io scheduler noop registered > Dec 26 15:59:37 box [ 0.243573] io scheduler anticipatory registered (default) > Dec 26 15:59:37 box [ 0.246317] Real Time Clock Driver v1.12ac > Dec 26 15:59:37 box [ 0.246370] Linux agpgart interface v0.101 (c) Dave Jones > Dec 26 15:59:37 box [ 0.246462] agpgart: Detected an Intel i875 Chipset. > Dec 26 15:59:37 box [ 0.250882] agpgart: AGP aperture is 128M @ 0xe8000000 > Dec 26 15:59:37 box [ 0.250958] Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled > Dec 26 15:59:37 box [ 0.251133] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > Dec 26 15:59:37 box [ 0.251356] Floppy drive(s): fd0 is 1.44M > Dec 26 15:59:37 box [ 0.267012] FDC 0 is a post-1991 82077 > Dec 26 15:59:37 box [ 0.268351] loop: loaded (max 8 devices) > Dec 26 15:59:37 box [ 0.268442] Intel(R) PRO/1000 Network Driver - version 7.2.9-k4-NAPI > Dec 26 15:59:37 box [ 0.268493] Copyright (c) 1999-2006 Intel Corporation. > Dec 26 15:59:37 box [ 0.268600] ACPI: PCI Interrupt 0000:02:01.0[A] -> GSI 18 (level, low) -> IRQ 16 > Dec 26 15:59:37 box [ 0.604067] e1000: 0000:02:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:50:8d:f1:07:38 > Dec 26 15:59:37 box [ 0.834733] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection > Dec 26 15:59:37 box [ 0.834892] netconsole: device eth0 not up yet, forcing it > Dec 26 15:59:37 box [ 3.322054] e1000: eth0: e1000_watchdog: NIC Link is Up 1000 Mbps Full Duplex > Dec 26 15:59:37 box [ 3.332192] netconsole: network logging started > Dec 26 15:59:37 box [ 3.332249] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > Dec 26 15:59:37 box [ 3.332302] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > Dec 26 15:59:37 box [ 3.332399] ICH5: IDE controller at PCI slot 0000:00:1f.1 > Dec 26 15:59:37 box [ 3.332458] ACPI: PCI Interrupt 0000:00:1f.1[A] -> > Dec 26 15:59:37 box GSI 18 (level, low) -> IRQ 16 > Dec 26 15:59:37 box [ 3.332563] ICH5: chipset revision 2 > Dec 26 15:59:37 box [ 3.332613] ICH5: not 100% native mode: will probe irqs later > Dec 26 15:59:37 box [ 3.332671] ide0: BM-DMA at 0xf000-0xf007 > Dec 26 15:59:37 box , BIOS settings: hda:DMA, hdb:pio > Dec 26 15:59:37 box > Dec 26 15:59:37 box [ 3.332815] ide1: BM-DMA at 0xf008-0xf00f > Dec 26 15:59:37 box , BIOS settings: hdc:DMA, hdd:pio > Dec 26 15:59:37 box > Dec 26 15:59:38 box [ 4.003579] hda: _NEC DVD_RW ND-3550A, > Dec 26 15:59:38 box ATAPI > Dec 26 15:59:38 box CD/DVD-ROM > Dec 26 15:59:38 box drive > Dec 26 15:59:39 box [ 4.615066] ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > Dec 26 15:59:39 box > Dec 26 15:59:39 box [ 5.286214] hdc: LITE-ON LTR-52246S, > Dec 26 15:59:39 box ATAPI > Dec 26 15:59:39 box CD/DVD-ROM > Dec 26 15:59:39 box drive > Dec 26 15:59:40 box [ 5.594037] ide1 at 0x170-0x177,0x376 on irq 15 > Dec 26 15:59:40 box > Dec 26 15:59:40 box [ 5.594975] hda: ATAPI > Dec 26 15:59:40 box 48X > Dec 26 15:59:40 box DVD-ROM > Dec 26 15:59:40 box DVD-R > Dec 26 15:59:40 box CD-R/RW > Dec 26 15:59:40 box drive > Dec 26 15:59:40 box , 2048kB Cache > Dec 26 15:59:40 box , UDMA(33) > Dec 26 15:59:40 box > Dec 26 15:59:40 box [ 5.595335] Uniform CD-ROM driver Revision: 3.20 > Dec 26 15:59:40 box [ 5.605270] hdc: ATAPI > Dec 26 15:59:40 box 52X > Dec 26 15:59:40 box CD-ROM > Dec 26 15:59:40 box CD-R/RW > Dec 26 15:59:40 box drive > Dec 26 15:59:40 box , 2048kB Cache > Dec 26 15:59:40 box , UDMA(33) > Dec 26 15:59:40 box > Dec 26 15:59:40 box [ 5.644915] ACPI: PCI Interrupt 0000:03:06.0[A] -> > Dec 26 15:59:40 box GSI 22 (level, low) -> IRQ 17 > Dec 26 15:59:43 box [ 8.646272] scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0 > Dec 26 15:59:43 box [ 8.646274] > Dec 26 15:59:43 box [ 8.646275] aic7850: Single Channel A, SCSI Id=7, 3/253 SCBs > Dec 26 15:59:43 box [ 8.646277] > Dec 26 15:59:44 box [ 10.481100] ata_piix 0000:00:1f.2: MAP [ > Dec 26 15:59:44 box P0 > Dec 26 15:59:44 box -- > Dec 26 15:59:44 box P1 > Dec 26 15:59:44 box -- > Dec 26 15:59:44 box ] > Dec 26 15:59:44 box [ 10.481347] ACPI: PCI Interrupt 0000:00:1f.2[A] -> > Dec 26 15:59:44 box GSI 18 (level, low) -> IRQ 16 > Dec 26 15:59:44 box [ 10.481502] ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 irq 16 > Dec 26 15:59:44 box [ 10.481591] ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 irq 16 > Dec 26 15:59:44 box [ 10.481651] scsi1 : ata_piix > Dec 26 15:59:45 box [ 10.635214] ata1.00: ATA-7, max UDMA7, 488397168 sectors: LBA48 NCQ (depth 0/32) > Dec 26 15:59:45 box [ 10.635279] ata1.00: ata1: dev 0 multi count 16 > Dec 26 15:59:45 box [ 10.665619] ata1.00: configured for UDMA/133 > Dec 26 15:59:45 box [ 10.665674] scsi2 : ata_piix > Dec 26 15:59:45 box [ 10.827315] ATA: abnormal status 0x7F on port 0xC807 > Dec 26 15:59:45 box [ 10.827469] scsi 1:0:0:0: Direct-Access ATA SAMSUNG SP2504C VT10 PQ: 0 ANSI: 5 > Dec 26 15:59:45 box [ 10.827651] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) > Dec 26 15:59:45 box [ 10.828414] sda: Write Protect is off > Dec 26 15:59:45 box [ 10.828492] SCSI device sda: drive cache: write back > Dec 26 15:59:45 box [ 10.828601] SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB) > Dec 26 15:59:45 box [ 10.828667] sda: Write Protect is off > Dec 26 15:59:45 box [ 10.828746] SCSI device sda: drive cache: write back > Dec 26 15:59:45 box [ 10.828798] sda: > Dec 26 15:59:45 box sda1 > Dec 26 15:59:45 box sda2 > Dec 26 15:59:45 box > Dec 26 15:59:45 box [ 10.838140] sd 1:0:0:0: Attached scsi disk sda > Dec 26 15:59:45 box [ 10.838277] sd 1:0:0:0: Attached scsi generic sg0 type 0 > Dec 26 15:59:45 box [ 10.840768] serio: i8042 KBD port at 0x60,0x64 irq 1 > Dec 26 15:59:45 box [ 10.840824] serio: i8042 AUX port at 0x60,0x64 irq 12 > Dec 26 15:59:45 box [ 10.840947] mice: PS/2 mouse device common for all mice > Dec 26 15:59:45 box [ 10.841165] input: PC Speaker as /class/input/input0 > Dec 26 15:59:45 box [ 10.870150] input: AT Translated Set 2 keyboard as /class/input/input1 > Dec 26 15:59:45 box [ 10.874664] i2c /dev entries driver > Dec 26 15:59:45 box [ 10.875229] Advanced Linux Sound Architecture Driver Version 1.0.13 (Tue Nov 28 14:07:24 2006 UTC). > Dec 26 15:59:45 box [ 10.875551] ACPI: PCI Interrupt 0000:03:05.0[A] -> > Dec 26 15:59:45 box GSI 21 (level, low) -> IRQ 18 > Dec 26 15:59:45 box [ 10.899119] ALSA device list: > Dec 26 15:59:45 box [ 10.899176] #0: SBLive! Value [CT4832] (rev.7, serial:0x80271102) at 0x9400, irq 18 > Dec 26 15:59:45 box [ 10.899241] TCP cubic registered > Dec 26 15:59:45 box [ 10.899313] NET: Registered protocol family 1 > Dec 26 15:59:45 box [ 10.899373] NET: Registered protocol family 17 > Dec 26 15:59:45 box [ 10.899465] Testing NMI watchdog ... > Dec 26 15:59:45 box OK. > Dec 26 15:59:45 box [ 10.909531] Starting balanced_irq > Dec 26 15:59:45 box [ 10.909586] Using IPI Shortcut mode > Dec 26 15:59:45 box [ 10.909755] Time: tsc clocksource has been installed. > Dec 26 15:59:46 box [ 11.582043] input: ImPS/2 Generic Wheel Mouse as /class/input/input2 > Dec 26 15:59:46 box [ 11.638471] UDF-fs: No VRS found > Dec 26 15:59:46 box [ 11.670420] XFS mounting filesystem sda2 > Dec 26 15:59:46 box [ 11.748382] VFS: Mounted root (xfs filesystem) readonly. > Dec 26 15:59:46 box [ 11.748601] Freeing unused kernel memory: 216k freed > Dec 26 15:59:48 box [ 13.956518] BUG: unable to handle kernel paging request > Dec 26 15:59:48 box at virtual address fffb9600 > Dec 26 15:59:48 box [ 13.956649] printing eip: > Dec 26 15:59:48 box [ 13.956703] c0149018 > Dec 26 15:59:48 box [ 13.956754] *pde = 00003067 > Dec 26 15:59:48 box [ 13.956811] *pte = 00000000 > Dec 26 15:59:48 box [ 13.956880] Oops: 0000 [#1] > Dec 26 15:59:48 box [ 13.956944] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.957101] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.957206] CPU: 0 > Dec 26 15:59:48 box [ 13.957207] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 13.957209] EFLAGS: 00010286 (2.6.19 #2) > Dec 26 15:59:48 box [ 13.957381] EIP is at do_wp_page+0xec/0x431 > Dec 26 15:59:48 box [ 13.957438] eax: fffb8000 ebx: fffb8000 ecx: 00000280 edx: c0003ee0 > Dec 26 15:59:48 box [ 13.957505] esi: fffb9600 edi: fffb8600 ebp: c1ff06a0 esp: f7b8bed4 > Dec 26 15:59:48 box [ 13.957574] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 13.957638] Process udevd (pid: 560, ti=f7b8a000 task=c2157a90 task.ti=f7b8a000) > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.957695] Stack: > Dec 26 15:59:48 box c1ff3ce0 > Dec 26 15:59:48 box 00000004 > Dec 26 15:59:48 box 7f835065 > Dec 26 15:59:48 box fffb9000 > Dec 26 15:59:48 box b7e4502c > Dec 26 15:59:48 box f7be11d0 > Dec 26 15:59:48 box f7b84040 > Dec 26 15:59:48 box c1ff3ce0 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.958140] > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box f7410914 > Dec 26 15:59:48 box f741bb7c > Dec 26 15:59:48 box f7b84088 > Dec 26 15:59:48 box 00000007 > Dec 26 15:59:48 box c014a740 > Dec 26 15:59:48 box f7410914 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.958579] > Dec 26 15:59:48 box f741bb7c > Dec 26 15:59:48 box f7b84088 > Dec 26 15:59:48 box 7f835065 > Dec 26 15:59:48 box c016c06c > Dec 26 15:59:48 box c21334ac > Dec 26 15:59:48 box c21334ac > Dec 26 15:59:48 box f7b75954 > Dec 26 15:59:48 box f7b84088 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.959044] Call Trace: > Dec 26 15:59:48 box [ 13.959146] [] > Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 > Dec 26 15:59:48 box [ 13.959246] [] > Dec 26 15:59:48 box dentry_iput+0x6b/0xba > Dec 26 15:59:48 box [ 13.959345] [] > Dec 26 15:59:48 box mntput_no_expire+0x1c/0x7d > Dec 26 15:59:48 box [ 13.959458] [] > Dec 26 15:59:48 box __fput+0x174/0x1c2 > Dec 26 15:59:48 box [ 13.959568] [] > Dec 26 15:59:48 box do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box [ 13.959678] [] > Dec 26 15:59:48 box do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 13.959772] [] > Dec 26 15:59:48 box error_code+0x39/0x40 > Dec 26 15:59:48 box [ 13.959878] [] > Dec 26 15:59:48 box schedule_timeout+0xa5/0xb0 > Dec 26 15:59:48 box [ 13.959987] ======================= > Dec 26 15:59:48 box [ 13.960049] Code: > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box e8 > Dec 26 15:59:48 box d1 > Dec 26 15:59:48 box a9 > Dec 26 15:59:48 box fc > Dec 26 15:59:48 box ff > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 44 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box c7 > Dec 26 15:59:48 box 44 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 04 > Dec 26 15:59:48 box 04 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 8b > Dec 26 15:59:48 box 54 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 1c > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 14 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box e8 > Dec 26 15:59:48 box b9 > Dec 26 15:59:48 box a9 > Dec 26 15:59:48 box fc > Dec 26 15:59:48 box ff > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box b9 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 04 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box c7 > Dec 26 15:59:48 box 8b > Dec 26 15:59:48 box 74 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box f3> > Dec 26 15:59:48 box a5 > Dec 26 15:59:48 box c7 > Dec 26 15:59:48 box 44 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 04 > Dec 26 15:59:48 box 03 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 8b > Dec 26 15:59:48 box 44 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 04 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box e8 > Dec 26 15:59:48 box 2a > Dec 26 15:59:48 box aa > Dec 26 15:59:48 box fc > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.962884] EIP: [] > Dec 26 15:59:48 box do_wp_page+0xec/0x431 > Dec 26 15:59:48 box SS:ESP 0068:f7b8bed4 > Dec 26 15:59:48 box [ 13.963041] > Dec 26 15:59:48 box note: udevd[560] exited with preempt_count 2 > Dec 26 15:59:48 box [ 13.963925] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 13.963997] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 13.964061] invalid opcode: 0000 [#2] > Dec 26 15:59:48 box [ 13.964114] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.964254] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.964367] CPU: 0 > Dec 26 15:59:48 box [ 13.964368] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 13.964372] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 13.964534] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 13.964596] eax: 7f9e7163 ebx: fffff000 ecx: c1ff7400 edx: c0003ee0 > Dec 26 15:59:48 box [ 13.964664] esi: 00000004 edi: 00000000 ebp: c1ff2860 esp: f7457ec8 > Dec 26 15:59:48 box [ 13.964731] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 13.964789] Process udevd (pid: 555, ti=f7456000 task=c21b4a90 task.ti=f7456000) > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.964850] Stack: > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box f7bc2918 > Dec 26 15:59:48 box c014900b > Dec 26 15:59:48 box c1ff7400 > Dec 26 15:59:48 box 00000004 > Dec 26 15:59:48 box 7f943065 > Dec 26 15:59:48 box fffb9000 > Dec 26 15:59:48 box b7e4617c > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.965343] > Dec 26 15:59:48 box f7bc3da0 > Dec 26 15:59:48 box f7b84ac0 > Dec 26 15:59:48 box c1ff7400 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box f7bc2918 > Dec 26 15:59:48 box f7beab7c > Dec 26 15:59:48 box f7b84b08 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.965790] > Dec 26 15:59:48 box 00000007 > Dec 26 15:59:48 box c014a740 > Dec 26 15:59:48 box f7bc2918 > Dec 26 15:59:48 box f7beab7c > Dec 26 15:59:48 box f7b84b08 > Dec 26 15:59:48 box 7f943065 > Dec 26 15:59:48 box c016c06c > Dec 26 15:59:48 box c21334ac > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.966286] Call Trace: > Dec 26 15:59:48 box [ 13.966401] [] > Dec 26 15:59:48 box do_wp_page+0xdf/0x431 > Dec 26 15:59:48 box [ 13.966513] [] > Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 > Dec 26 15:59:48 box [ 13.966617] [] > Dec 26 15:59:48 box dentry_iput+0x6b/0xba > Dec 26 15:59:48 box [ 13.966720] [] > Dec 26 15:59:48 box mntput_no_expire+0x1c/0x7d > Dec 26 15:59:48 box [ 13.966836] [] > Dec 26 15:59:48 box __fput+0x174/0x1c2 > Dec 26 15:59:48 box [ 13.966938] [] > Dec 26 15:59:48 box do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box [ 13.967038] [] > Dec 26 15:59:48 box do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 13.967152] [] > Dec 26 15:59:48 box error_code+0x39/0x40 > Dec 26 15:59:48 box [ 13.967265] [] > Dec 26 15:59:48 box schedule_timeout+0xa5/0xb0 > Dec 26 15:59:48 box [ 13.967383] ======================= > Dec 26 15:59:48 box [ 13.967450] Code: > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box c2 > Dec 26 15:59:48 box 8b > Dec 26 15:59:48 box 02 > Dec 26 15:59:48 box 85 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 75 > Dec 26 15:59:48 box 21 > Dec 26 15:59:48 box 2b > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 80 > Dec 26 15:59:48 box 9d > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box f9 > Dec 26 15:59:48 box 05 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box e1 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 38 > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 0a > Dec 26 15:59:48 box 8d > Dec 26 15:59:48 box 46 > Dec 26 15:59:48 box 43 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box e0 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box d8 > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box f> > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 2a > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 49 > Dec 26 15:59:48 box 22 > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box eb > Dec 26 15:59:48 box d5 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 4c > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box e9 > Dec 26 15:59:48 box 5c > Dec 26 15:59:48 box 4a > Dec 26 15:59:48 box 03 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.970382] EIP: [] > Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box SS:ESP 0068:f7457ec8 > Dec 26 15:59:48 box [ 13.970545] > Dec 26 15:59:48 box note: udevd[555] exited with preempt_count 2 > Dec 26 15:59:48 box [ 13.971027] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 13.971089] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 13.971148] invalid opcode: 0000 [#3] > Dec 26 15:59:48 box [ 13.971208] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.971356] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.971447] CPU: 0 > Dec 26 15:59:48 box [ 13.971449] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 13.971452] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 13.971634] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 13.971696] eax: 7f943163 ebx: fffff000 ecx: c1ff4760 edx: c0003ee4 > Dec 26 15:59:48 box [ 13.971756] esi: 00000003 edi: 00000080 ebp: f7e37db8 esp: f7e37ce0 > Dec 26 15:59:48 box [ 13.971824] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 13.971895] Process udevd (pid: 522, ti=f7e36000 task=c2155a90 task.ti=f7e36000) > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.971968] Stack: > Dec 26 15:59:48 box f7f1d280 > Dec 26 15:59:48 box 00000080 > Dec 26 15:59:48 box c013d03c > Dec 26 15:59:48 box c1ff4760 > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box f7aa42d0 > Dec 26 15:59:48 box 00000202 > Dec 26 15:59:48 box 00000080 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.972437] > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c1ff4760 > Dec 26 15:59:48 box f7aa42d0 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c013dac4 > Dec 26 15:59:48 box f7e37db8 > Dec 26 15:59:48 box c1ff4760 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.972894] > Dec 26 15:59:48 box 00000891 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box f7e37d54 > Dec 26 15:59:48 box f7aa4220 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.973381] Call Trace: > Dec 26 15:59:48 box [ 13.973481] [] > Dec 26 15:59:48 box file_read_actor+0xbb/0xf6 > Dec 26 15:59:48 box [ 13.973581] [] > Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c > Dec 26 15:59:48 box [ 13.973679] [] > Dec 26 15:59:48 box generic_file_aio_read+0xfb/0x270 > Dec 26 15:59:48 box [ 13.973774] [] > Dec 26 15:59:48 box file_read_actor+0x0/0xf6 > Dec 26 15:59:48 box [ 13.973871] [] > Dec 26 15:59:48 box xfs_read+0x180/0x3c1 > Dec 26 15:59:48 box [ 13.973971] [] > Dec 26 15:59:48 box __link_path_walk+0x82c/0xda7 > Dec 26 15:59:48 box [ 13.974080] [] > Dec 26 15:59:48 box xfs_file_aio_read+0x70/0x84 > Dec 26 15:59:48 box [ 13.974192] [] > Dec 26 15:59:48 box do_sync_read+0xf0/0x126 > Dec 26 15:59:48 box [ 13.974302] [] > Dec 26 15:59:48 box autoremove_wake_function+0x0/0x4b > Dec 26 15:59:48 box [ 13.974404] [] > Dec 26 15:59:48 box try_to_wake_up+0x40/0x402 > Dec 26 15:59:48 box [ 13.974500] [] > Dec 26 15:59:48 box __next_cpu+0x22/0x33 > Dec 26 15:59:48 box [ 13.974601] [] > Dec 26 15:59:48 box vfs_read+0x9d/0x17b > Dec 26 15:59:48 box [ 13.974714] [] > Dec 26 15:59:48 box kernel_read+0x49/0x59 > Dec 26 15:59:48 box [ 13.974820] [] > Dec 26 15:59:48 box prepare_binprm+0xbf/0xf0 > Dec 26 15:59:48 box [ 13.974923] [] > Dec 26 15:59:48 box do_execve+0xec/0x1dc > Dec 26 15:59:48 box [ 13.975019] [] > Dec 26 15:59:48 box sys_execve+0x3c/0x97 > Dec 26 15:59:48 box [ 13.975117] [] > Dec 26 15:59:48 box syscall_call+0x7/0xb > Dec 26 15:59:48 box [ 13.975234] [] > Dec 26 15:59:48 box schedule_timeout+0xa5/0xb0 > Dec 26 15:59:48 box [ 13.975345] ======================= > Dec 26 15:59:48 box [ 13.975401] Code: > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box c2 > Dec 26 15:59:48 box 8b > Dec 26 15:59:48 box 02 > Dec 26 15:59:48 box 85 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 75 > Dec 26 15:59:48 box 21 > Dec 26 15:59:48 box 2b > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 80 > Dec 26 15:59:48 box 9d > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box f9 > Dec 26 15:59:48 box 05 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box e1 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 38 > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 0a > Dec 26 15:59:48 box 8d > Dec 26 15:59:48 box 46 > Dec 26 15:59:48 box 43 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box e0 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box d8 > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box f> > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 2a > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 49 > Dec 26 15:59:48 box 22 > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box eb > Dec 26 15:59:48 box d5 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 4c > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box e9 > Dec 26 15:59:48 box 5c > Dec 26 15:59:48 box 4a > Dec 26 15:59:48 box 03 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.978193] EIP: [] > Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box note: udevd[522] exited with preempt_count 1 > Dec 26 15:59:48 box [ 13.978847] ------------[ cut here ]------------ > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.979481] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box > Dec 26 15:59:48 box c0141f9a > Dec 26 15:59:48 box c046bd80 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 13.981214] Call Trace: > Dec 26 15:59:48 box [ 13.982205] [] > Dec 26 15:59:48 box __alloc_pages+0x4f/0x2db > Dec 26 15:59:48 box [ 13.982756] [] > Dec 26 15:59:48 box [ 13.982985] ======================= > Dec 26 15:59:48 box 85 > Dec 26 15:59:48 box 80 > Dec 26 15:59:48 box e1 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 4c > Dec 26 15:59:48 box 5c > Dec 26 15:59:48 box [ 13.986129] > Dec 26 15:59:48 box note: scsi_id[503] exited with preempt_count 1 > Dec 26 15:59:48 box [ 13.986580] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 13.986947] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 13.987317] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box c013d03c > Dec 26 15:59:48 box 00000080 > Dec 26 15:59:48 box c1ff37c0 > Dec 26 15:59:48 box f740bd54 > Dec 26 15:59:48 box [ 13.988878] [] > Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c > Dec 26 15:59:48 box xfs_read+0x180/0x3c1 > Dec 26 15:59:48 box [ 13.989838] [] > Dec 26 15:59:48 box sched_balance_self+0x13b/0x2e3 > Dec 26 15:59:48 box [ 13.990457] [] > Dec 26 15:59:48 box syscall_call+0x7/0xb > Dec 26 15:59:48 box c2 > Dec 26 15:59:48 box 21 > Dec 26 15:59:48 box 05 > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 43 > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box > Dec 26 15:59:48 box note: udevd[534] exited with preempt_count 1 > Dec 26 15:59:48 box [ 13.994411] ------------[ cut here ]------------ > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 4a > Dec 26 15:59:48 box [ 14.035590] > Dec 26 15:59:48 box [ 14.036042] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.036206] PREEMPT > Dec 26 15:59:48 box [ 14.036449] CPU: 0 > Dec 26 15:59:48 box > Dec 26 15:59:48 box c0148ff3 > Dec 26 15:59:48 box 0805f794 > Dec 26 15:59:48 box f7417080 > Dec 26 15:59:48 box f7b84248 > Dec 26 15:59:48 box [ 14.038497] [] > Dec 26 15:59:48 box do_page_fault+0x0/0x651 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box 75 > Dec 26 15:59:48 box e1 > Dec 26 15:59:48 box 0a > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box [ 14.042223] > Dec 26 15:59:48 box [ 14.042667] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.042856] PREEMPT > Dec 26 15:59:48 box [ 14.043120] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.043476] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box c1ff1d80 > Dec 26 15:59:48 box > Dec 26 15:59:48 box f7b08080 > Dec 26 15:59:48 box c014a740 > Dec 26 15:59:48 box [ 14.045003] Call Trace: > Dec 26 15:59:48 box [ 14.045341] [] > Dec 26 15:59:48 box error_code+0x39/0x40 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 8d > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box > Dec 26 15:59:48 box note: udevd[474] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.049495] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.049551] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.050516] invalid opcode: 0000 [#13] > Dec 26 15:59:48 box [ 14.050573] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box [ 14.050833] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 14.051183] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box c046bd80 > Dec 26 15:59:48 box [ 14.052157] > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box [ 14.052822] [] > Dec 26 15:59:48 box [ 14.053047] [] > Dec 26 15:59:48 box do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 14.053672] [] > Dec 26 15:59:48 box file_read_actor+0x0/0xf6 > Dec 26 15:59:48 box [ 14.054299] [] > Dec 26 15:59:48 box vfs_read+0x9d/0x17b > Dec 26 15:59:48 box [ 14.054931] [] > Dec 26 15:59:48 box 8b > Dec 26 15:59:48 box 9d > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 0a > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box f> > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box note: udevd[518] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.058569] ------------[ cut here ]------------ > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.059035] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box [ 14.059997] > Dec 26 15:59:48 box [ 14.060465] > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.061279] [] > Dec 26 15:59:48 box do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box [ 14.061926] [] > Dec 26 15:59:48 box [ 14.062146] [] > Dec 26 15:59:48 box get_unused_fd+0xbe/0xcf > Dec 26 15:59:48 box [ 14.063032] [] > Dec 26 15:59:48 box syscall_call+0x7/0xb > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 2b > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box 38 > Dec 26 15:59:48 box 43 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 49 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box note: udevd[488] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.068364] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.068432] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.068492] invalid opcode: 0000 [#15] > Dec 26 15:59:48 box [ 14.068555] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.068808] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.069161] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box fffb9000 > Dec 26 15:59:48 box c1ff5ca0 > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box 00000db2 > Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 > Dec 26 15:59:48 box do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box [ 14.071491] [] > Dec 26 15:59:48 box [ 14.071767] Code: > Dec 26 15:59:48 box 75 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box d8 > Dec 26 15:59:48 box eb > Dec 26 15:59:48 box [ 14.074634] EIP: [] > Dec 26 15:59:48 box note: S03udev[632] exited with preempt_count 2 > Dec 26 15:59:48 box [ 14.076251] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.076333] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.076399] invalid opcode: 0000 [#16] > Dec 26 15:59:48 box [ 14.076465] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box [ 14.076615] Modules linked in: > Dec 26 15:59:48 box [ 14.077088] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.077205] Stack: > Dec 26 15:59:48 box f7a3f160 > Dec 26 15:59:48 box f7e83dd0 > Dec 26 15:59:48 box [ 14.078163] > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.078858] [] > Dec 26 15:59:48 box [ 14.079088] [] > Dec 26 15:59:48 box [ 14.079511] [] > Dec 26 15:59:48 box autoremove_wake_function+0x0/0x4b > Dec 26 15:59:48 box sys_read+0x4b/0x74 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box 00000080 > Dec 26 15:59:48 box f7b7eed0 > Dec 26 15:59:48 box 00001000 > Dec 26 15:59:48 box > Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c > Dec 26 15:59:48 box xfs_read+0x180/0x3c1 > Dec 26 15:59:48 box do_sync_read+0xf0/0x126 > Dec 26 15:59:48 box [ 14.097192] [] > Dec 26 15:59:48 box prepare_binprm+0xbf/0xf0 > Dec 26 15:59:48 box [ 14.097817] [] > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box 2b > Dec 26 15:59:48 box f9 > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box 43 > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 4a > Dec 26 15:59:48 box note: udevd[497] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.101348] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.101407] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.101781] CPU: 0 > Dec 26 15:59:48 box [ 14.102144] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box f7b77174 > Dec 26 15:59:48 box > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box c014a740 > Dec 26 15:59:48 box c224fa90 > Dec 26 15:59:48 box [ 14.104054] [] > Dec 26 15:59:48 box [ 14.104285] [] > Dec 26 15:59:48 box [ 14.104689] Code: > Dec 26 15:59:48 box 02 > Dec 26 15:59:48 box 9d > Dec 26 15:59:48 box 05 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box 43 > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box e9 > Dec 26 15:59:48 box 5c > Dec 26 15:59:48 box > Dec 26 15:59:48 box note: udevd[494] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.108249] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.108721] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.109013] esi: 00000003 edi: 00000080 ebp: f7b8fdb8 esp: f7b8fce0 > Dec 26 15:59:48 box c013d03c > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box f7b8fdb8 > Dec 26 15:59:48 box 00000006 > Dec 26 15:59:48 box [ 14.110608] Call Trace: > Dec 26 15:59:48 box generic_file_aio_read+0xfb/0x270 > Dec 26 15:59:48 box [ 14.111271] [] > Dec 26 15:59:48 box autoremove_wake_function+0x0/0x4b > Dec 26 15:59:48 box [ 14.111881] [] > Dec 26 15:59:48 box prepare_binprm+0xbf/0xf0 > Dec 26 15:59:48 box schedule_timeout+0xa5/0xb0 > Dec 26 15:59:48 box c2 > Dec 26 15:59:48 box 9d > Dec 26 15:59:48 box 05 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box f> > Dec 26 15:59:48 box d5 > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.115962] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.116030] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.116373] CPU: 0 > Dec 26 15:59:48 box [ 14.116744] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.116857] Stack: > Dec 26 15:59:48 box 0805b2d0 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c014a740 > Dec 26 15:59:48 box c046a6a0 > Dec 26 15:59:48 box [ 14.118469] [] > Dec 26 15:59:48 box memmove+0x3f/0x48 > Dec 26 15:59:48 box [ 14.119445] [] > Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 > Dec 26 15:59:48 box file_free_rcu+0x18/0x1c > Dec 26 15:59:48 box do_page_fault+0x0/0x651 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box 85 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 0a > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box f> > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box > Dec 26 15:59:48 box note: udevd[496] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.123658] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.123994] Modules linked in: > Dec 26 15:59:48 box [ 14.124267] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.124463] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box c1ff47c0 > Dec 26 15:59:48 box > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box [ 14.126032] Call Trace: > Dec 26 15:59:48 box [ 14.126356] [] > Dec 26 15:59:48 box __link_path_walk+0x82c/0xda7 > Dec 26 15:59:48 box [ 14.126999] [] > Dec 26 15:59:48 box [ 14.127331] [] > Dec 26 15:59:48 box prepare_binprm+0xbf/0xf0 > Dec 26 15:59:48 box [ 14.127996] [] > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 75 > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box eb > Dec 26 15:59:48 box 5c > Dec 26 15:59:48 box SS:ESP 0068:f7b97ce0 > Dec 26 15:59:48 box [ 14.131704] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.131830] invalid opcode: 0000 [#23] > Dec 26 15:59:48 box [ 14.132078] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 14.132134] Call Trace: > Dec 26 15:59:48 box [ 14.132145] [] wake_bit_function+0x0/0x34 > Dec 26 15:59:48 box [ 14.132196] [] do_sync_read+0xf0/0x126 > Dec 26 15:59:48 box [ 14.132227] [] kernel_read+0x49/0x59 > Dec 26 15:59:48 box [ 14.132325] <6>note: udevd[535] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.132544] PREEMPT SMP > Dec 26 15:59:48 box [ 14.132570] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.132620] [] do_wp_page+0xc7/0x431 > Dec 26 15:59:48 box [ 14.132662] [] error_code+0x39/0x40 > Dec 26 15:59:48 box [ 14.132890] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.132926] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.132962] [] file_read_actor+0xbb/0xf6 > Dec 26 15:59:48 box [ 14.132996] [] __link_path_walk+0x82c/0xda7 > Dec 26 15:59:48 box [ 14.133040] [] prepare_binprm+0xbf/0xf0 > Dec 26 15:59:48 box [ 14.133066] ======================= > Dec 26 15:59:48 box [ 14.133124] EIP: [] kmap_atomic+0x7f/0x94 SS:ESP 0068:f74b1ce0 > Dec 26 15:59:48 box [ 14.133276] PREEMPT SMP > Dec 26 15:59:48 box [ 14.133291] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.133327] 00000000 c1ff47c0 f7453d7c 00000000 c013dac4 f7453db8 c1ff47c0 00000000 > Dec 26 15:59:48 box [ 14.139180] Call Trace: > Dec 26 15:59:48 box [ 14.139198] [] do_wp_page+0x386/0x431 > Dec 26 15:59:48 box [ 14.139223] ======================= > Dec 26 15:59:48 box [ 14.139472] [] skb_queue_purge+0x1a/0x23 > Dec 26 15:59:48 box [ 14.139508] [] pipe_read_release+0x24/0x36 > Dec 26 15:59:48 box [ 14.139557] [] do_invalid_op+0xab/0xb4 > Dec 26 15:59:48 box [ 14.139584] [] bitmap_parse_user+0x37/0x57 > Dec 26 15:59:48 box [ 14.139628] [] syscall_call+0x7/0xb > Dec 26 15:59:48 box [ 14.139730] PREEMPT SMP > Dec 26 15:59:48 box [ 14.139761] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.135224] Call Trace: > Dec 26 15:59:48 box [ 14.135248] [] xfs_read+0x180/0x3c1 > Dec 26 15:59:48 box [ 14.135279] [] try_to_wake_up+0x40/0x402 > Dec 26 15:59:48 box [ 14.135405] <6>note: udevd[639] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.135599] invalid opcode: 0000 [#32] > Dec 26 15:59:48 box [ 14.135675] Call Trace: > Dec 26 15:59:48 box [ 14.135688] [] do_wait+0x55a/0xb55 > Dec 26 15:59:48 box [ 14.135719] ======================= > Dec 26 15:59:48 box [ 14.135980] PREEMPT SMP > Dec 26 15:59:48 box [ 14.135993] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.136044] Call Trace: > Dec 26 15:59:48 box [ 14.136070] [] do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box [ 14.136075] [] do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 14.136080] [] error_code+0x39/0x40 > Dec 26 15:59:48 box [ 14.136089] ======================= > Dec 26 15:59:48 box [ 14.136289] invalid opcode: 0000 [#34] > Dec 26 15:59:48 box [ 14.136309] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.136366] Call Trace: > Dec 26 15:59:48 box [ 14.136382] [] do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 14.136432] [] kmap_high+0x60/0x1f7 > Dec 26 15:59:48 box [ 14.136462] [] search_binary_handler+0xab/0x266 > Dec 26 15:59:48 box [ 14.136550] <6>note: modprobe[665] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.136648] PREEMPT SMP > Dec 26 15:59:48 box [ 14.136683] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.136730] Call Trace: > Dec 26 15:59:48 box [ 14.136767] [] error_code+0x39/0x40 > Dec 26 15:59:48 box [ 14.136839] <6>note: udevd[657] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.136994] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.137051] Call Trace: > Dec 26 15:59:48 box [ 14.137077] [] generic_file_aio_read+0xfb/0x270 > Dec 26 15:59:48 box [ 14.137117] [] try_to_wake_up+0x40/0x402 > Dec 26 15:59:48 box [ 14.137145] [] sys_execve+0x3c/0x97 > Dec 26 15:59:48 box [ 14.137396] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.137473] Call Trace: > Dec 26 15:59:48 box [ 14.137475] [] do_wp_page+0xc7/0x431 > Dec 26 15:59:48 box [ 14.137504] [] schedule_timeout+0xa5/0xb0 > Dec 26 15:59:48 box [ 14.137820] invalid opcode: 0000 [#38] > Dec 26 15:59:48 box [ 14.137837] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.137841] eax: 7fe86163 ebx: fffff000 ecx: c1fff060 edx: c0003ee4 > Dec 26 15:59:48 box [ 14.137847] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.137870] 00000007 c014a740 f74c0180 f744f080 f741f088 7ff83045 00000280 c2248030 > Dec 26 15:59:48 box [ 14.137909] [] error_code+0x39/0x40 > Dec 26 15:59:48 box [ 14.137965] EIP: [] kmap_atomic+0x7f/0x94 SS:ESP 0068:f74dbec8 > Dec 26 15:59:48 box [ 14.138258] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.138275] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.138321] [] __handle_mm_fault+0x6fa/0x997 > Dec 26 15:59:48 box [ 14.138353] [] do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 14.138622] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.138644] CPU: 0 > Dec 26 15:59:48 box [ 14.138710] Call Trace: > Dec 26 15:59:48 box [ 14.138713] [] do_wp_page+0xc7/0x431 > Dec 26 15:59:48 box [ 14.138754] ======================= > Dec 26 15:59:48 box [ 14.139107] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.139127] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.139180] Call Trace: > Dec 26 15:59:48 box [ 14.139204] [] autoremove_wake_function+0x0/0x4b > Dec 26 15:59:48 box [ 14.139288] <6>note: udevd[465] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.139489] [] __mutex_lock_slowpath+0x50/0x89 > Dec 26 15:59:48 box [ 14.139553] [] do_invalid_op+0x0/0xb4 > Dec 26 15:59:48 box [ 14.139578] [] error_code+0x39/0x40 > Dec 26 15:59:48 box [ 14.139624] [] sys_write+0x4b/0x74 > Dec 26 15:59:48 box [ 14.139737] CPU: 0 > Dec 26 15:59:48 box [ 14.139761] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.139804] Call Trace: > Dec 26 15:59:48 box [ 14.139807] [] do_wp_page+0xc7/0x431 > Dec 26 15:59:48 box [ 14.139812] [] __handle_mm_fault+0x6fa/0x997 > Dec 26 15:59:48 box [ 14.139823] [] __fput+0x174/0x1c2 > Dec 26 15:59:48 box [ 14.139852] ======================= > Dec 26 15:59:48 box [ 14.140230] PREEMPT SMP > Dec 26 15:59:48 box [ 14.140261] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.140303] Call Trace: > Dec 26 15:59:48 box [ 14.140325] [] do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box [ 14.140412] <6>note: udevd[656] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.140621] Modules linked in: > Dec 26 15:59:48 box [ 14.140644] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.140684] Call Trace: > Dec 26 15:59:48 box [ 14.140713] [] do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 14.140978] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.140994] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.141051] Call Trace: > Dec 26 15:59:48 box [ 14.141076] [] do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box [ 14.141158] <6>note: udevd[654] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.141911] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.141967] Call Trace: > Dec 26 15:59:48 box [ 14.142009] [] do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 14.170666] ------------[ cut here ]------------ > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box [ 14.171329] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.171432] Stack: > Dec 26 15:59:48 box [ 14.171816] > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab > Dec 26 15:59:48 box do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box error_code+0x39/0x40 > Dec 26 15:59:48 box [ 14.174004] ======================= > Dec 26 15:59:48 box [ 14.174052] Code: > Dec 26 15:59:48 box 75 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box 43 > Dec 26 15:59:48 box f> > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box > Dec 26 15:59:48 box note: udevd[495] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.183278] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.183348] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.183407] invalid opcode: 0000 [#48] > Dec 26 15:59:48 box [ 14.183465] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.183605] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.183702] CPU: 0 > Dec 26 15:59:48 box [ 14.183703] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.183704] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 14.183854] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.183905] eax: 7fe86163 ebx: fffff000 ecx: c1ff3fe0 edx: c0003ee4 > Dec 26 15:59:48 box [ 14.183958] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f7539e64 > Dec 26 15:59:48 box [ 14.184010] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.184060] Process modprobe (pid: 681, ti=f7538000 task=c224ea90 task.ti=f7538000) > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.184114] Stack: > Dec 26 15:59:48 box c1ff3fe0 > Dec 26 15:59:48 box c1ff3fe0 > Dec 26 15:59:48 box c0141f9a > Dec 26 15:59:48 box c1ff3fe0 > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box 000001b2 > Dec 26 15:59:48 box c046bc00 > Dec 26 15:59:48 box 000280d2 > Dec 26 15:59:48 box [ 14.185342] [] > Dec 26 15:59:48 box [ 14.185695] [] > Dec 26 15:59:48 box [ 14.185955] ======================= > Dec 26 15:59:48 box 75 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box SS:ESP 0068:f7539e64 > Dec 26 15:59:48 box [ 14.192143] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.192211] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.192264] invalid opcode: 0000 [#49] > Dec 26 15:59:48 box [ 14.192318] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.192440] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.192529] CPU: 0 > Dec 26 15:59:48 box [ 14.192531] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.192533] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 14.192695] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.192754] eax: 7fe86163 ebx: fffff000 ecx: c1ffbba0 edx: c0003ee4 > Dec 26 15:59:48 box [ 14.192871] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box c1ffbba0 > Dec 26 15:59:48 box [ 14.193385] > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab > Dec 26 15:59:48 box [ 14.194689] [] > Dec 26 15:59:48 box file_read_actor+0x22/0xf6 > Dec 26 15:59:48 box [ 14.195304] [] > Dec 26 15:59:48 box [ 14.195566] [] > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 80 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box 0a > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box SS:ESP 0068:f7533bb4 > Dec 26 15:59:48 box [ 14.211977] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.212045] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.212103] invalid opcode: 0000 [#50] > Dec 26 15:59:48 box [ 14.212159] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.212290] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.212376] CPU: 0 > Dec 26 15:59:48 box [ 14.212377] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.212378] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 14.212527] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.212577] eax: 7fe86163 ebx: fffff000 ecx: c1ff61e0 edx: c0003ee4 > Dec 26 15:59:48 box [ 14.212630] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f7535bb4 > Dec 26 15:59:48 box [ 14.212683] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.212733] Process modprobe (pid: 679, ti=f7534000 task=c21d6030 task.ti=f7534000) > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.212786] Stack: > Dec 26 15:59:48 box c1ff61e0 > Dec 26 15:59:48 box c1ff61e0 > Dec 26 15:59:48 box c0141f9a > Dec 26 15:59:48 box c1ff61e0 > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box 000001b2 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000044 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.213165] > Dec 26 15:59:48 box c046bd80 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c046bc00 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.213544] > Dec 26 15:59:48 box 000280d2 > Dec 26 15:59:48 box c046bfa0 > Dec 26 15:59:48 box 00000282 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box f7535c50 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box c046bfa0 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.213923] Call Trace: > Dec 26 15:59:48 box [ 14.214014] [] > Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab > Dec 26 15:59:48 box __handle_mm_fault+0x83a/0x997 > Dec 26 15:59:48 box do_page_fault+0x0/0x651 > Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c > Dec 26 15:59:48 box get_unused_fd+0xbe/0xcf > Dec 26 15:59:48 box [ 14.215500] [] > Dec 26 15:59:48 box [ 14.215759] ======================= > Dec 26 15:59:48 box 21 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box d8 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box SS:ESP 0068:f7535bb4 > Dec 26 15:59:48 box [ 14.218603] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.218708] invalid opcode: 0000 [#51] > Dec 26 15:59:48 box [ 14.219105] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box f74fe168 > Dec 26 15:59:48 box > Dec 26 15:59:48 box > Dec 26 15:59:48 box f74fbcc8 > Dec 26 15:59:48 box __handle_mm_fault+0x6fa/0x997 > Dec 26 15:59:48 box do_page_fault+0x0/0x651 > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box 21 > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 8d > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box eb > Dec 26 15:59:48 box 4a > Dec 26 15:59:48 box [ 14.223732] > Dec 26 15:59:48 box [ 14.233317] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.233377] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.233433] invalid opcode: 0000 [#52] > Dec 26 15:59:48 box [ 14.233486] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.233610] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.233696] CPU: 0 > Dec 26 15:59:48 box [ 14.233697] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.233698] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 14.233844] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.233895] eax: 7fe86163 ebx: fffff000 ecx: c1ff5680 edx: c0003ee4 > Dec 26 15:59:48 box [ 14.233948] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f7537bb4 > Dec 26 15:59:48 box [ 14.234692] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.234742] Process modprobe (pid: 680, ti=f7536000 task=f7476560 task.ti=f7536000) > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.234796] Stack: > Dec 26 15:59:48 box c1ff5680 > Dec 26 15:59:48 box c1ff5680 > Dec 26 15:59:48 box c0141f9a > Dec 26 15:59:48 box c1ff5680 > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box 000001b2 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000044 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.235175] > Dec 26 15:59:48 box c046bd80 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c046bc00 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.235552] > Dec 26 15:59:48 box 000280d2 > Dec 26 15:59:48 box c046bfa0 > Dec 26 15:59:48 box [ 14.236198] [] > Dec 26 15:59:48 box __sched_text_start+0x40c/0xaf3 > Dec 26 15:59:48 box file_read_actor+0x22/0xf6 > Dec 26 15:59:48 box [ 14.237192] [] > Dec 26 15:59:48 box [ 14.237540] [] > Dec 26 15:59:48 box [ 14.237798] [] > Dec 26 15:59:48 box 85 > Dec 26 15:59:48 box f9 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box e0 > Dec 26 15:59:48 box 2a > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 03 > Dec 26 15:59:48 box note: modprobe[680] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.240812] invalid opcode: 0000 [#53] > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.241410] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box c0148ff3 > Dec 26 15:59:48 box c1ff7b60 > Dec 26 15:59:48 box f7b90168 > Dec 26 15:59:48 box do_wp_page+0xc7/0x431 > Dec 26 15:59:48 box [ 14.243180] [] > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 38 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 22 > Dec 26 15:59:48 box e9 > Dec 26 15:59:48 box note: udevd[671] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.265589] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.265643] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.265693] invalid opcode: 0000 [#54] > Dec 26 15:59:48 box [ 14.265742] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.265858] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.265942] CPU: 0 > Dec 26 15:59:48 box [ 14.265943] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.265944] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 14.266092] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.266142] eax: 7fe86163 ebx: fffff000 ecx: c1ff7740 edx: c0003ee4 > Dec 26 15:59:48 box [ 14.266195] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f753bbb4 > Dec 26 15:59:48 box [ 14.266247] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.266297] Process modprobe (pid: 682, ti=f753a000 task=f7476a90 task.ti=f753a000) > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.266350] Stack: > Dec 26 15:59:48 box c1ff7740 > Dec 26 15:59:48 box c1ff7740 > Dec 26 15:59:48 box c0141f9a > Dec 26 15:59:48 box c1ff7740 > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box 000001b2 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000044 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.266728] > Dec 26 15:59:48 box c046bd80 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c046bc00 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.267106] > Dec 26 15:59:48 box 000280d2 > Dec 26 15:59:48 box c046bfa0 > Dec 26 15:59:48 box 00000282 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c0515324 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box c046bfa0 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.267483] Call Trace: > Dec 26 15:59:48 box [ 14.267574] [] > Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab > Dec 26 15:59:48 box [ 14.267663] [] > Dec 26 15:59:48 box __alloc_pages+0x4f/0x2db > Dec 26 15:59:48 box [ 14.267750] [] > Dec 26 15:59:48 box __handle_mm_fault+0x83a/0x997 > Dec 26 15:59:48 box [ 14.267839] [] > Dec 26 15:59:48 box __sched_text_start+0x40c/0xaf3 > Dec 26 15:59:48 box [ 14.267927] [] > Dec 26 15:59:48 box __sched_text_start+0x43c/0xaf3 > Dec 26 15:59:48 box [ 14.268014] [] > Dec 26 15:59:48 box do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box [ 14.268102] [] > Dec 26 15:59:48 box do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 14.268188] [] > Dec 26 15:59:48 box error_code+0x39/0x40 > Dec 26 15:59:48 box [ 14.268274] [] > Dec 26 15:59:48 box file_read_actor+0x22/0xf6 > Dec 26 15:59:48 box [ 14.268362] [] > Dec 26 15:59:48 box wake_bit_function+0x0/0x34 > Dec 26 15:59:48 box [ 14.268449] [] > Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c > Dec 26 15:59:48 box [ 14.268538] [] > Dec 26 15:59:48 box generic_file_aio_read+0xfb/0x270 > Dec 26 15:59:48 box [ 14.268625] [] > Dec 26 15:59:48 box file_read_actor+0x0/0xf6 > Dec 26 15:59:48 box [ 14.268711] [] > Dec 26 15:59:48 box xfs_read+0x180/0x3c1 > Dec 26 15:59:48 box get_unused_fd+0xbe/0xcf > Dec 26 15:59:48 box sys_read+0x4b/0x74 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box f9 > Dec 26 15:59:48 box 38 > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box [ 14.442714] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.442774] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.442825] invalid opcode: 0000 [#55] > Dec 26 15:59:48 box [ 14.442874] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.442991] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.443077] CPU: 0 > Dec 26 15:59:48 box [ 14.443078] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.443079] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 14.443228] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.443278] eax: 7fe86163 ebx: fffff000 ecx: c1ff5040 edx: c0003ee4 > Dec 26 15:59:48 box [ 14.443332] esi: 00000003 edi: 00000001 ebp: 00000000 esp: f78b3e64 > Dec 26 15:59:48 box [ 14.443384] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.443434] Process rc (pid: 377, ti=f78b2000 task=c2155030 task.ti=f78b2000) > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.443478] Stack: > Dec 26 15:59:48 box c1ff5040 > Dec 26 15:59:48 box c1ff5040 > Dec 26 15:59:48 box c0141f9a > Dec 26 15:59:48 box c1ff5040 > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box 000001b2 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000044 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.443858] > Dec 26 15:59:48 box c046bd80 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c046bc00 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000002 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.444236] > Dec 26 15:59:48 box 000280d2 > Dec 26 15:59:48 box c046bfa0 > Dec 26 15:59:48 box 00000282 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box c046bfa0 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.444616] Call Trace: > Dec 26 15:59:48 box [ 14.444707] [] > Dec 26 15:59:48 box get_page_from_freelist+0x299/0x3ab > Dec 26 15:59:48 box [ 14.444797] [] > Dec 26 15:59:48 box __alloc_pages+0x4f/0x2db > Dec 26 15:59:48 box [ 14.444883] [] > Dec 26 15:59:48 box cp_new_stat64+0x103/0x115 > Dec 26 15:59:48 box [ 14.444971] [] > Dec 26 15:59:48 box __handle_mm_fault+0x83a/0x997 > Dec 26 15:59:48 box [ 14.445059] [] > Dec 26 15:59:48 box vma_merge+0x136/0x1c5 > Dec 26 15:59:48 box [ 14.445146] [] > Dec 26 15:59:48 box do_brk+0x17b/0x219 > Dec 26 15:59:48 box [ 14.445232] [] > Dec 26 15:59:48 box do_page_fault+0x49b/0x651 > Dec 26 15:59:48 box [ 14.445319] [] > Dec 26 15:59:48 box do_page_fault+0x0/0x651 > Dec 26 15:59:48 box [ 14.445405] [] > Dec 26 15:59:48 box error_code+0x39/0x40 > Dec 26 15:59:48 box [ 14.445492] ======================= > Dec 26 15:59:48 box [ 14.445541] Code: > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box c2 > Dec 26 15:59:48 box 8b > Dec 26 15:59:48 box 02 > Dec 26 15:59:48 box 85 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 75 > Dec 26 15:59:48 box 21 > Dec 26 15:59:48 box 2b > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 80 > Dec 26 15:59:48 box 9d > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box f9 > Dec 26 15:59:48 box 05 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box e1 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 38 > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 0a > Dec 26 15:59:48 box 8d > Dec 26 15:59:48 box 46 > Dec 26 15:59:48 box 43 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box e0 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box d8 > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box f> > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 2a > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 49 > Dec 26 15:59:48 box 22 > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box eb > Dec 26 15:59:48 box d5 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 4c > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box e9 > Dec 26 15:59:48 box 5c > Dec 26 15:59:48 box 4a > Dec 26 15:59:48 box 03 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.447903] EIP: [] > Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box SS:ESP 0068:f78b3e64 > Dec 26 15:59:48 box [ 14.448028] > Dec 26 15:59:48 box note: rc[377] exited with preempt_count 1 > Dec 26 15:59:48 box [ 14.448896] ------------[ cut here ]------------ > Dec 26 15:59:48 box [ 14.448953] kernel BUG at arch/i386/mm/highmem.c:42! > Dec 26 15:59:48 box [ 14.449004] invalid opcode: 0000 [#56] > Dec 26 15:59:48 box [ 14.449053] PREEMPT > Dec 26 15:59:48 box SMP > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.449170] Modules linked in: > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.449255] CPU: 0 > Dec 26 15:59:48 box [ 14.449256] EIP: 0060:[] Not tainted VLI > Dec 26 15:59:48 box [ 14.449257] EFLAGS: 00010206 (2.6.19 #2) > Dec 26 15:59:48 box [ 14.449406] EIP is at kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box [ 14.449456] eax: 7fe86163 ebx: fffff000 ecx: c1fff360 edx: c0003ee4 > Dec 26 15:59:48 box [ 14.449509] esi: 00000003 edi: 00000180 ebp: c2121e0c esp: c2121d34 > Dec 26 15:59:48 box [ 14.449562] ds: 007b es: 007b ss: 0068 > Dec 26 15:59:48 box [ 14.449614] Process init (pid: 1, ti=c2120000 task=c211ca90 task.ti=c2120000) > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.449658] Stack: > Dec 26 15:59:48 box b7f68460 > Dec 26 15:59:48 box 00000180 > Dec 26 15:59:48 box c013d03c > Dec 26 15:59:48 box c1fff360 > Dec 26 15:59:48 box 00000003 > Dec 26 15:59:48 box c1fff360 > Dec 26 15:59:48 box c01443c5 > Dec 26 15:59:48 box 00000180 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.450036] > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c1fff360 > Dec 26 15:59:48 box c2121dd0 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box c013dac4 > Dec 26 15:59:48 box c2121e0c > Dec 26 15:59:48 box c1fff360 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.450413] > Dec 26 15:59:48 box 00001000 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box c2121da8 > Dec 26 15:59:48 box f796f820 > Dec 26 15:59:48 box 00000005 > Dec 26 15:59:48 box 00000000 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box 00000001 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.450793] Call Trace: > Dec 26 15:59:48 box [ 14.450884] [] > Dec 26 15:59:48 box file_read_actor+0xbb/0xf6 > Dec 26 15:59:48 box [ 14.450973] [] > Dec 26 15:59:48 box activate_page+0x1e/0x99 > Dec 26 15:59:48 box [ 14.451060] [] > Dec 26 15:59:48 box do_generic_mapping_read+0x2c5/0x52c > Dec 26 15:59:48 box [ 14.451149] [] > Dec 26 15:59:48 box generic_file_aio_read+0xfb/0x270 > Dec 26 15:59:48 box [ 14.451237] [] > Dec 26 15:59:48 box file_read_actor+0x0/0xf6 > Dec 26 15:59:48 box [ 14.452013] [] > Dec 26 15:59:48 box xfs_read+0x180/0x3c1 > Dec 26 15:59:48 box [ 14.452100] [] > Dec 26 15:59:48 box get_unused_fd+0xbe/0xcf > Dec 26 15:59:48 box [ 14.452189] [] > Dec 26 15:59:48 box xfs_file_aio_read+0x70/0x84 > Dec 26 15:59:48 box [ 14.452276] [] > Dec 26 15:59:48 box do_sync_read+0xf0/0x126 > Dec 26 15:59:48 box [ 14.452362] [] > Dec 26 15:59:48 box enqueue_hrtimer+0x52/0x83 > Dec 26 15:59:48 box [ 14.452449] [] > Dec 26 15:59:48 box autoremove_wake_function+0x0/0x4b > Dec 26 15:59:48 box [ 14.452537] [] > Dec 26 15:59:48 box fcntl_setlk+0x44/0x231 > Dec 26 15:59:48 box [ 14.452626] [] > Dec 26 15:59:48 box vfs_read+0x9d/0x17b > Dec 26 15:59:48 box [ 14.452711] [] > Dec 26 15:59:48 box sys_read+0x4b/0x74 > Dec 26 15:59:48 box [ 14.452796] [] > Dec 26 15:59:48 box syscall_call+0x7/0xb > Dec 26 15:59:48 box [ 14.452882] ======================= > Dec 26 15:59:48 box [ 14.452930] Code: > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box c2 > Dec 26 15:59:48 box 8b > Dec 26 15:59:48 box 02 > Dec 26 15:59:48 box 85 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 75 > Dec 26 15:59:48 box 21 > Dec 26 15:59:48 box 2b > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 80 > Dec 26 15:59:48 box 9d > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box f9 > Dec 26 15:59:48 box 05 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box e1 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 0d > Dec 26 15:59:48 box 38 > Dec 26 15:59:48 box 52 > Dec 26 15:59:48 box 51 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 0a > Dec 26 15:59:48 box 8d > Dec 26 15:59:48 box 46 > Dec 26 15:59:48 box 43 > Dec 26 15:59:48 box c1 > Dec 26 15:59:48 box e0 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 29 > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box d8 > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box c3 > Dec 26 15:59:48 box f> > Dec 26 15:59:48 box 0b > Dec 26 15:59:48 box 2a > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box 49 > Dec 26 15:59:48 box 22 > Dec 26 15:59:48 box 41 > Dec 26 15:59:48 box c0 > Dec 26 15:59:48 box eb > Dec 26 15:59:48 box d5 > Dec 26 15:59:48 box 89 > Dec 26 15:59:48 box 4c > Dec 26 15:59:48 box 24 > Dec 26 15:59:48 box 0c > Dec 26 15:59:48 box 5b > Dec 26 15:59:48 box 5e > Dec 26 15:59:48 box e9 > Dec 26 15:59:48 box 5c > Dec 26 15:59:48 box 4a > Dec 26 15:59:48 box 03 > Dec 26 15:59:48 box 00 > Dec 26 15:59:48 box > Dec 26 15:59:48 box [ 14.455288] EIP: [] > Dec 26 15:59:48 box kmap_atomic+0x7f/0x94 > Dec 26 15:59:48 box SS:ESP 0068:c2121d34 > Dec 26 15:59:48 box [ 14.455412] > Dec 26 15:59:48 box Kernel panic - not syncing: Attempted to kill init! > Dec 26 15:59:49 box [ 14.455556] > From owner-xfs@oss.sgi.com Thu Dec 28 17:52:36 2006 Received: with ECARTIS (v1.0.0; list xfs); Thu, 28 Dec 2006 17:52:42 -0800 (PST) Received: from taiwan.yingternet.net (taiwan.yingternet.net [59.124.122.220]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBT1qYqw004672 for ; Thu, 28 Dec 2006 17:52:35 -0800 Message-ID: <459474A7.2090902@yingternet.com> Date: Fri, 29 Dec 2006 09:51:35 +0800 From: Ying-Hung Chen User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: chatz@melbourne.sgi.com CC: linux-xfs@oss.sgi.com Subject: Re: xfs_repair xfsprogs version > 2.8.11 References: <458E643D.3090008@yingternet.com> <458FA0F8.1020107@yingternet.com> <45939ABD.6010600@melbourne.sgi.com> In-Reply-To: <45939ABD.6010600@melbourne.sgi.com> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 10152 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ying@yingternet.com Precedence: bulk X-list: xfs Content-Length: 3197 Lines: 117 Hi David, on 2.4 side, I am running the kernel based on 2.4.33, using gcc 3.4.4, glibc-2.3.5, ulimit yields core file size (blocks, -c) 0 data seg size (kbytes, -d) 60144 file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) unlimited on 2.6 side, I have kernel based on 2.6.16.32, using gcc 4.1.1 and glibc-2.3.6, ulimit yields core file size (blocks, -c) 0 data seg size (kbytes, -d) 12288 file size (blocks, -f) unlimited pending signals (-i) 1535 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 256 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 100 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited anything that you need for better pin point the problem? also, is the stacksize resizing really necessary as showed in ... stacksize *= 4; ... Thanks -Ying David Chatterton wrote: > Ying-Hung, > > Can you please provide some info on your configuration? Obviously we are > not seeing this problem in our own tests and reproducing this will help > to resolve it. > > Thanks, > > David > > > Ying-Hung Chen wrote: >> Hi there, >> >> actually, i have trace the code in to xfs_repair/threads.c (taken from >> 2.8.18) >> >> void >> thread_init(void) >> { >> .... >> if ((status = pthread_attr_getstacksize(&attr, &stacksize)) != 0) >> do_error(_("status from pthread_attr_getstacksize: %d"), >> status); >> >> stacksize *= 4; >> >> if ((status = pthread_attr_setstacksize(&attr, stacksize)) != 0) >> do_error(_("status from pthread_attr_setstacksize: %d"), >> status); >> .... >> } >> >> the repair program dies in pthread_attr_setstacksize(&attr, stacksize)). >> is there any reason why the program is trying to set the stacksize into >> 4 times the current size? >> >> just for testing purposes, I remove the stacksize *= 4; the xfs_repair >> seems to 'work', at least from user's point of view. >> >> I have tested with x86 32bits machines with 2.4 and 2.6 kernels, they >> both yield with the same results, >> >> Thanks, >> >> -Ying >> >> Ying-Hung Chen wrote: >>> Hi there, >>> >>> I found that xfs_repair always returns the following message with the >>> xfsprogs version > 2.8.11 >>> >>> [root@yroro i586]# xfs_repair /dev/hdb1 >>> >>> fatal error -- status from pthread_attr_setstacksize: 22 >>> >>> from the ChangeLog, seems like there is some internal changes with >>> threads starting 2.8.11 .. the xfs_repair works for me up to 2.8.11, it >>> fails to work on 2.8.16 and 2.8.18, >>> >>> how do I work around this problem? >>> >>> Thanks, >>> >>> -Ying >>> > From owner-xfs@oss.sgi.com Sun Dec 31 06:32:53 2006 Received: with ECARTIS (v1.0.0; list xfs); Sun, 31 Dec 2006 06:32:58 -0800 (PST) Received: from tmailer.gwdg.de (tmailer.gwdg.de [134.76.10.23]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id kBVEWpqw020522 for ; Sun, 31 Dec 2006 06:32:52 -0800 Received: from linux01.gwdg.de ([134.76.13.21]) by mailer.gwdg.de with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1H10w1-0003K3-4P for xfs@oss.sgi.com; Sun, 31 Dec 2006 14:41:09 +0100 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id kBVDf9Lr019441 for ; Sun, 31 Dec 2006 14:41:11 +0100 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id kBVDf9I4019435 for ; Sun, 31 Dec 2006 14:41:09 +0100 Date: Sun, 31 Dec 2006 14:41:09 +0100 (MET) From: Jan Engelhardt To: xfs@oss.sgi.com Subject: xfs internal error on sparc64 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 10155 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@linux01.gwdg.de Precedence: bulk X-list: xfs Content-Length: 3133 Lines: 75 Hi list, just catched this in dmesg: xfs_da_do_buf: bno 16777216 dir: inode 134659821 Filesystem "sdf5": XFS internal error xfs_da_do_buf(1) at line 1992 of file fs/xfs/xfs_da_btree.c. Caller 0x000000001002b53c Call Trace: [00000000100325c4] xfs_dir2_node_removename+0x1e4/0x400 [xfs] [000000001002def4] xfs_dir_removename+0x12c/0x138 [xfs] [00000000100583e4] xfs_remove+0x258/0x410 [xfs] [0000000010061afc] xfs_vn_unlink+0x24/0x58 [xfs] [00000000004b2c40] vfs_unlink+0xf4/0x144 [00000000004b4fa4] do_unlinkat+0xa8/0x148 [0000000000406c54] linux_sparc_syscall32+0x3c/0x40 [000000000001f898] 0x1f8a0 Filesystem "sdf5": XFS internal error xfs_trans_cancel at line 1138 of file fs/xfs/xfs_trans.c. Caller 0x0000000010058568 Call Trace: [0000000010061afc] xfs_vn_unlink+0x24/0x58 [xfs] [00000000004b2c40] vfs_unlink+0xf4/0x144 [00000000004b4fa4] do_unlinkat+0xa8/0x148 [0000000000406c54] linux_sparc_syscall32+0x3c/0x40 [000000000001f898] 0x1f8a0 xfs_force_shutdown(sdf5,0x8) called from line 1139 of file fs/xfs/xfs_trans.c. Return address = 0x0000000010064ce4 Filesystem "sdf5": Corruption of in-memory data detected. Shutting down filesystem: sdf5 Please umount the filesystem, and rectify the problem(s) xfs_force_shutdown(sdf5,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0x0000000010064ce4 xfs_force_shutdown(sdf5,0x1) called from line 424 of file fs/xfs/xfs_rw.c. Return address = 0x0000000010064ce4 /proc/modules: xfs 468241 1 - Live 0x000000001000a000 Currently-running kernel is 2.6.18-1.2798.al3.1smp. Beforehand, only 2.6.16-1.2241sp7smp and 2.6.13-1.1603sp13smp were running, so I do not think it is the directory corruption bug that slipped in in 2.6.17. # umount /dev/sdf5 # xfs_check /dev/sdf5 ERROR: The filesystem has valuable metadata changes in a log which needs to be replayed. Mount the filesystem to replay the log, and unmount it before re-running xfs_ncheck. If you are unable to mount the filesystem, then use the xfs_repair -L option to destroy the log and attempt a repair. Note that destroying the log may cause corruption -- please attempt a mount of the filesystem before doing this. must run blockget -n first # mount /dev/sdf5 # umount /dev/sdf5 # xfs_check /dev/sdf5 bad free block nused 9 should be 31 for dir ino 520 block 16777216 bad free block nused 0 should be 32 for dir ino 17294340 block 16777216 bad free block nused 0 should be 26 for dir ino 17554166 block 16777216 bad free block nused 0 should be 32 for dir ino 17554169 block 16777216 bad free block nused 2 should be 9 for dir ino 33809210 block 16777216 bad free block nused 1 should be 16 for dir ino 33902514 block 16777216 bad free block nused 0 should be 26 for dir ino 50408697 block 16777216 bad free block nused 0 should be 45 for dir ino 83894051 block 16777216 bad free block nused 0 should be 43 for dir ino 100746327 block 16777216 bad free block nused 0 should be 5 for dir ino 134490771 block 16777216 missing free index for data block 0 in dir ino 134659821 It's still the 16777216 bug? Anyway, I am going to run xfs_repair 2.8.11 now and see. -`J' --