Re: [PATCH 2/2] ASLR: add possibility for more fine-grained tweaking
At Thursday 07 February 2008 around 12:23:50 Geert Uytterhoeven wrote: > On Wed, 6 Feb 2008, Ingo Molnar wrote: > > @@ -541,6 +541,18 @@ config ELF_CORE > > help > > Enable support for generating core dumps. Disabling saves about > > 4k. > > +config COMPAT_BRK > > + bool "Disable heap randomization" > > + default y > > + help > > + Randomizing heap placement makes heap exploits harder, but it > > + also breaks ancient binaries (including anything libc5 based). > > + This option changes the bootup default to heap randomization > > + disabled, and can be overriden runtime by setting > > + /proc/sys/kernel/randomize_va_space to 2. > > + > > + On non-ancient distros (post-2000 ones) Y is usually a safe > > choice. > > Somehow my belly feeling tells me something is wrong with this > description... > > Ah, a negative option (Y -> disable). So Y is always safe. > > `non-ancient distros' really means `recent distros', and if you have one, > then _N_ should be a safe choice, too? This indeed looks wrong. The default should be N and the text should say "On recent distros (post-2000 ones) N is usually a safe choice". Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] ASLR: add possibility for more fine-grained tweaking
At Thursday 07 February 2008 around 12:23:50 Geert Uytterhoeven wrote: On Wed, 6 Feb 2008, Ingo Molnar wrote: @@ -541,6 +541,18 @@ config ELF_CORE help Enable support for generating core dumps. Disabling saves about 4k. +config COMPAT_BRK + bool Disable heap randomization + default y + help + Randomizing heap placement makes heap exploits harder, but it + also breaks ancient binaries (including anything libc5 based). + This option changes the bootup default to heap randomization + disabled, and can be overriden runtime by setting + /proc/sys/kernel/randomize_va_space to 2. + + On non-ancient distros (post-2000 ones) Y is usually a safe choice. Somehow my belly feeling tells me something is wrong with this description... Ah, a negative option (Y - disable). So Y is always safe. `non-ancient distros' really means `recent distros', and if you have one, then _N_ should be a safe choice, too? This indeed looks wrong. The default should be N and the text should say On recent distros (post-2000 ones) N is usually a safe choice. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] per-process securebits
At Monday 04 February 2008 around 18:45:24 Serge E. Hallyn wrote: > Quoting Andrew G. Morgan ([EMAIL PROTECTED]): > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Ismail D??nmez wrote: > > | What I meant to ask was what does "per-process securebits" brings as > > > > extra. > > > > It allows you to create a legacy free process tree. For example, a > > chroot, or container (which Serge can obviously explain in more detail), > > (Just to give my thoughts on securebits and containers) > > A container is a set of processes which has its own private namespaces > for all or most resources - for instance it sees only processes in its > own pid namespace, and its first process, which is sees as pid 1, is > known as some other pid, maybe 3459, to the rest of the system. > > We tend to talk about 'system containers' versus 'application > containers'. A system container would be like a vserver or openvz > instance, something which looks like a separate machine. I was > going to say I don't imagine per-process securebits being useful > there, but actually since a system container doesn't need to do any > hardware setup it actually might be a much easier start for a full > SECURE_NOROOT distro than a real machine. Heck, on a real machine init > and a few legacy deamons could run in the init namespace, while users > log in and apache etc run in a SECURE_NOROOT container. > > But I especially like the thought of for instance postfix running in a > carefully crafted application container (with its own virtual network > card and limited file tree and no visibility of other processes) with > SECURE_NOROOT on. This is really interesting security wise, will be nice to see how it can be implemented in real life. Thanks for the explanation and the implementation ;-) Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] per-process securebits
At Monday 04 February 2008 around 18:45:24 Serge E. Hallyn wrote: Quoting Andrew G. Morgan ([EMAIL PROTECTED]): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ismail D??nmez wrote: | What I meant to ask was what does per-process securebits brings as extra. It allows you to create a legacy free process tree. For example, a chroot, or container (which Serge can obviously explain in more detail), (Just to give my thoughts on securebits and containers) A container is a set of processes which has its own private namespaces for all or most resources - for instance it sees only processes in its own pid namespace, and its first process, which is sees as pid 1, is known as some other pid, maybe 3459, to the rest of the system. We tend to talk about 'system containers' versus 'application containers'. A system container would be like a vserver or openvz instance, something which looks like a separate machine. I was going to say I don't imagine per-process securebits being useful there, but actually since a system container doesn't need to do any hardware setup it actually might be a much easier start for a full SECURE_NOROOT distro than a real machine. Heck, on a real machine init and a few legacy deamons could run in the init namespace, while users log in and apache etc run in a SECURE_NOROOT container. But I especially like the thought of for instance postfix running in a carefully crafted application container (with its own virtual network card and limited file tree and no visibility of other processes) with SECURE_NOROOT on. This is really interesting security wise, will be nice to see how it can be implemented in real life. Thanks for the explanation and the implementation ;-) Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] per-process securebits
At Monday 04 February 2008 around 02:49:29 Andrew G. Morgan wrote: > Another way to put this is that there needs to be some application code > and documentation available to guide the way... Adding such things to > the example programs in libcap2 helped me find the 24-rc2 CAP_SETPCAP > bug and until I've gone through the task of testing all the bits > together, I won't believe the kernel support is anything other than > 'experimental'. > > Other folk are actively advocating and exploring this model. For > example, Chris Friedhoff has a page here that describes some first > steps for using filesystem capabilities: > > ~ http://www.friedhoff.org/posixfilecaps.html I already know and enjoy File system base capabilities thanks to Chris' website and Serge's developerWorks article. What I meant to ask was what does "per-process securebits" brings as extra. FWIW in Pardus 2008 we'll enable Posix file capabilities by default so people could "harden" their setups. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] per-process securebits
At Monday 04 February 2008 around 02:49:29 Andrew G. Morgan wrote: Another way to put this is that there needs to be some application code and documentation available to guide the way... Adding such things to the example programs in libcap2 helped me find the 24-rc2 CAP_SETPCAP bug and until I've gone through the task of testing all the bits together, I won't believe the kernel support is anything other than 'experimental'. Other folk are actively advocating and exploring this model. For example, Chris Friedhoff has a page here that describes some first steps for using filesystem capabilities: ~ http://www.friedhoff.org/posixfilecaps.html I already know and enjoy File system base capabilities thanks to Chris' website and Serge's developerWorks article. What I meant to ask was what does per-process securebits brings as extra. FWIW in Pardus 2008 we'll enable Posix file capabilities by default so people could harden their setups. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] per-process securebits
At Sunday 03 February 2008 around 08:18:12 Andrew Morton wrote: > So how do we ever get to the stage where we can recommend that distributors > turn these things on, and have them agree with us? FWIW with my distributor hat on I think File system capabilities are very nice and enables one to ship a distribution with a small set of setuid binaries. On the other hand for per-process securebits, it would be nice to see a complete example how it could be applied to a setuid program. That would be a nice step in moving forward. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] GIT 1.5.4-rc3
Saturday 12 January 2008 09:11:23 tarihinde Junio C Hamano şunları yazmıştı:
> The third rc for the next feature release GIT 1.5.4 is available
> at the usual places:
>
> http://www.kernel.org/pub/software/scm/git/
>
> git-1.5.4.rc3.tar.{gz,bz2} (tarball)
> git-htmldocs-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
> git-manpages-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
> testing/git-*-1.5.4.rc3-1.$arch.rpm (RPM)
I am seeing new failures compared to rc2 :
*** t9200-git-cvsexportcommit.sh ***
* FAIL 1: New file
mkdir A B C D E F &&
echo hello1 >A/newfile1.txt &&
echo hello2 >B/newfile2.txt &&
cp ../test9200a.png C/newfile3.png &&
cp ../test9200a.png D/newfile4.png &&
git add A/newfile1.txt &&
git add B/newfile2.txt &&
git add C/newfile3.png &&
git add D/newfile4.png &&
git commit -a -m "Test: New file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "newfile1.txt/1.1/" &&
check_entries B "newfile2.txt/1.1/" &&
check_entries C "newfile3.png/1.1/-kb" &&
check_entries D "newfile4.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff B/newfile2.txt ../B/newfile2.txt &&
diff C/newfile3.png ../C/newfile3.png &&
diff D/newfile4.png ../D/newfile4.png
)
* FAIL 2: Remove two files, add two and update two
echo Hello1 >>A/newfile1.txt &&
rm -f B/newfile2.txt &&
rm -f C/newfile3.png &&
echo Hello5 >E/newfile5.txt &&
cp ../test9200b.png D/newfile4.png &&
cp ../test9200a.png F/newfile6.png &&
git add E/newfile5.txt &&
git add F/newfile6.png &&
git commit -a -m "Test: Remove, add and update" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "newfile1.txt/1.2/" &&
check_entries B "" &&
check_entries C "" &&
check_entries D "newfile4.png/1.2/-kb" &&
check_entries E "newfile5.txt/1.1/" &&
check_entries F "newfile6.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff D/newfile4.png ../D/newfile4.png &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 4: Remove only binary files
git reset --hard HEAD^^ &&
rm -f D/newfile4.png &&
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "newfile1.txt/1.2/" &&
check_entries B "" &&
check_entries C "" &&
check_entries D "" &&
check_entries E "newfile5.txt/1.1/" &&
check_entries F "newfile6.png/1.1/-kb" &&
diff A/newfile1.txt ../A/newfile1.txt &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 5: Remove only a text file
rm -f A/newfile1.txt &&
git commit -a -m "test: remove only a binary file" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git cvsexportcommit -c $id &&
check_entries A "" &&
check_entries B "" &&
check_entries C "" &&
check_entries D "" &&
check_entries E "newfile5.txt/1.1/" &&
check_entries F "newfile6.png/1.1/-kb" &&
diff E/newfile5.txt ../E/newfile5.txt &&
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 6: New file with spaces in file name
mkdir "G g" &&
echo ok then >"G g/with spaces.txt" &&
git add "G g/with spaces.txt" && \
cp ../test9200a.png "G g/with spaces.png" && \
git add "G g/with spaces.png" &&
git commit -a -m "With spaces" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -c $id &&
check_entries "G g" "with spaces.png/1.1/-kb|with
spaces.txt/1.1/"
)
* FAIL 7: Update file with spaces in file name
echo Ok then >>"G g/with spaces.txt" &&
cat ../test9200a.png >>"G g/with spaces.png" && \
git add "G g/with spaces.png" &&
git commit -a -m "Update with spaces" &&
id=$(git rev-list --max-count=1 HEAD) &&
(cd "$CVSWORK" &&
git-cvsexportcommit -c $id
check_entries "G g"
Re: [ANNOUNCE] GIT 1.5.4-rc3
Saturday 12 January 2008 09:11:23 tarihinde Junio C Hamano şunları yazmıştı:
The third rc for the next feature release GIT 1.5.4 is available
at the usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.4.rc3.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.4.rc3.tar.{gz,bz2} (preformatted docs)
testing/git-*-1.5.4.rc3-1.$arch.rpm (RPM)
I am seeing new failures compared to rc2 :
*** t9200-git-cvsexportcommit.sh ***
* FAIL 1: New file
mkdir A B C D E F
echo hello1 A/newfile1.txt
echo hello2 B/newfile2.txt
cp ../test9200a.png C/newfile3.png
cp ../test9200a.png D/newfile4.png
git add A/newfile1.txt
git add B/newfile2.txt
git add C/newfile3.png
git add D/newfile4.png
git commit -a -m Test: New file
id=$(git rev-list --max-count=1 HEAD)
(cd $CVSWORK
git cvsexportcommit -c $id
check_entries A newfile1.txt/1.1/
check_entries B newfile2.txt/1.1/
check_entries C newfile3.png/1.1/-kb
check_entries D newfile4.png/1.1/-kb
diff A/newfile1.txt ../A/newfile1.txt
diff B/newfile2.txt ../B/newfile2.txt
diff C/newfile3.png ../C/newfile3.png
diff D/newfile4.png ../D/newfile4.png
)
* FAIL 2: Remove two files, add two and update two
echo Hello1 A/newfile1.txt
rm -f B/newfile2.txt
rm -f C/newfile3.png
echo Hello5 E/newfile5.txt
cp ../test9200b.png D/newfile4.png
cp ../test9200a.png F/newfile6.png
git add E/newfile5.txt
git add F/newfile6.png
git commit -a -m Test: Remove, add and update
id=$(git rev-list --max-count=1 HEAD)
(cd $CVSWORK
git cvsexportcommit -c $id
check_entries A newfile1.txt/1.2/
check_entries B
check_entries C
check_entries D newfile4.png/1.2/-kb
check_entries E newfile5.txt/1.1/
check_entries F newfile6.png/1.1/-kb
diff A/newfile1.txt ../A/newfile1.txt
diff D/newfile4.png ../D/newfile4.png
diff E/newfile5.txt ../E/newfile5.txt
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 4: Remove only binary files
git reset --hard HEAD^^
rm -f D/newfile4.png
git commit -a -m test: remove only a binary file
id=$(git rev-list --max-count=1 HEAD)
(cd $CVSWORK
git cvsexportcommit -c $id
check_entries A newfile1.txt/1.2/
check_entries B
check_entries C
check_entries D
check_entries E newfile5.txt/1.1/
check_entries F newfile6.png/1.1/-kb
diff A/newfile1.txt ../A/newfile1.txt
diff E/newfile5.txt ../E/newfile5.txt
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 5: Remove only a text file
rm -f A/newfile1.txt
git commit -a -m test: remove only a binary file
id=$(git rev-list --max-count=1 HEAD)
(cd $CVSWORK
git cvsexportcommit -c $id
check_entries A
check_entries B
check_entries C
check_entries D
check_entries E newfile5.txt/1.1/
check_entries F newfile6.png/1.1/-kb
diff E/newfile5.txt ../E/newfile5.txt
diff F/newfile6.png ../F/newfile6.png
)
* FAIL 6: New file with spaces in file name
mkdir G g
echo ok then G g/with spaces.txt
git add G g/with spaces.txt \
cp ../test9200a.png G g/with spaces.png \
git add G g/with spaces.png
git commit -a -m With spaces
id=$(git rev-list --max-count=1 HEAD)
(cd $CVSWORK
git-cvsexportcommit -c $id
check_entries G g with spaces.png/1.1/-kb|with
spaces.txt/1.1/
)
* FAIL 7: Update file with spaces in file name
echo Ok then G g/with spaces.txt
cat ../test9200a.png G g/with spaces.png \
git add G g/with spaces.png
git commit -a -m Update with spaces
id=$(git rev-list --max-count=1 HEAD)
(cd $CVSWORK
git-cvsexportcommit -c $id
check_entries G g with spaces.png/1.2/-kb|with
spaces.txt/1.2/
)
* FAIL 8: File with non-ascii file name
mkdir -p
Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö
echo Foo
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
Saturday 05 January 2008 11:31:21 tarihinde şunları yazmıştınız: > On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote: > > The second util-linux-ng 2.13.1 release candidate is available at > > > > ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ > > Interesting. Thanks. Which distros are using this, or plan to do so? Pardus Linux switched to -ng for upcoming 2008 release. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2
Saturday 05 January 2008 11:31:21 tarihinde şunları yazmıştınız: On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak [EMAIL PROTECTED] wrote: The second util-linux-ng 2.13.1 release candidate is available at ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/ Interesting. Thanks. Which distros are using this, or plan to do so? Pardus Linux switched to -ng for upcoming 2008 release. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Sunday 09 December 2007 14:31:47 tarihinde Theodore Tso şunları yazmıştı: > On Sun, Dec 09, 2007 at 08:21:16AM +0200, Ismail Dönmez wrote: > > My understanding was if you can drain entropy from /dev/urandom any > > futher reads from /dev/urandom will result in data which is not random at > > all. Is that wrong? > > Past a certain point /dev/urandom will stat returning results which > are cryptographically random. At that point, you are depending on the > strength of the SHA hash algorithm, and actually being able to not > just to find hash collisions, but being able to trivially find all or > most possible pre-images for a particular SHA hash algorithm. If that > were to happen, it's highly likely that all digital signatures and > openssh would be totally broken. Thats very good news, thanks for the detailed explanation. Time to update common misconceptions. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Sunday 09 December 2007 14:31:47 tarihinde Theodore Tso şunları yazmıştı: On Sun, Dec 09, 2007 at 08:21:16AM +0200, Ismail Dönmez wrote: My understanding was if you can drain entropy from /dev/urandom any futher reads from /dev/urandom will result in data which is not random at all. Is that wrong? Past a certain point /dev/urandom will stat returning results which are cryptographically random. At that point, you are depending on the strength of the SHA hash algorithm, and actually being able to not just to find hash collisions, but being able to trivially find all or most possible pre-images for a particular SHA hash algorithm. If that were to happen, it's highly likely that all digital signatures and openssh would be totally broken. Thats very good news, thanks for the detailed explanation. Time to update common misconceptions. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Sunday 09 December 2007 01:46:12 tarihinde Theodore Tso şunları yazmıştı: > On Sun, Dec 09, 2007 at 12:10:10AM +0200, Ismail Dönmez wrote: > > > As long as /dev/random is readable for all users there's no reason to > > > use /dev/urandom for a local DoS... > > > > Draining entropy in /dev/urandom means that insecure and possibly not > > random data will be used and well thats a security bug if not a DoS bug. > > Actually in modern 2.6 kernels there are two separate output entropy > pools for /dev/random and /dev/urandom. So assuming that the > adversary doesn't know the contents of the current state of the > entropy pool (i.e., the RNG is well seeded with entropy), you can read > all you want from /dev/urandom and that won't give an adversary > successful information to attack /dev/random. My understanding was if you can drain entropy from /dev/urandom any futher reads from /dev/urandom will result in data which is not random at all. Is that wrong? Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Sunday 09 December 2007 00:03:45 tarihinde Adrian Bunk şunları yazmıştı: > On Thu, Dec 06, 2007 at 02:32:05PM -0500, Bill Davidsen wrote: > >... > > Sounds like a local DoS attack point to me... > > As long as /dev/random is readable for all users there's no reason to > use /dev/urandom for a local DoS... Draining entropy in /dev/urandom means that insecure and possibly not random data will be used and well thats a security bug if not a DoS bug. And yes this is by design, sigh. -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Sunday 09 December 2007 00:03:45 tarihinde Adrian Bunk şunları yazmıştı: On Thu, Dec 06, 2007 at 02:32:05PM -0500, Bill Davidsen wrote: ... Sounds like a local DoS attack point to me... As long as /dev/random is readable for all users there's no reason to use /dev/urandom for a local DoS... Draining entropy in /dev/urandom means that insecure and possibly not random data will be used and well thats a security bug if not a DoS bug. And yes this is by design, sigh. -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Sunday 09 December 2007 01:46:12 tarihinde Theodore Tso şunları yazmıştı: On Sun, Dec 09, 2007 at 12:10:10AM +0200, Ismail Dönmez wrote: As long as /dev/random is readable for all users there's no reason to use /dev/urandom for a local DoS... Draining entropy in /dev/urandom means that insecure and possibly not random data will be used and well thats a security bug if not a DoS bug. Actually in modern 2.6 kernels there are two separate output entropy pools for /dev/random and /dev/urandom. So assuming that the adversary doesn't know the contents of the current state of the entropy pool (i.e., the RNG is well seeded with entropy), you can read all you want from /dev/urandom and that won't give an adversary successful information to attack /dev/random. My understanding was if you can drain entropy from /dev/urandom any futher reads from /dev/urandom will result in data which is not random at all. Is that wrong? Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_IRQBALANCE for 64-bit x86 ?
Tuesday 20 November 2007 Tarihinde 06:12:21 yazmıştı: > On 32-bit x86, we have CONFIG_IRQBALANCE available, > but not on 64-bit x86. Why not? > > I ask, because this feature seems almost essential to obtaining > reasonable latencies during heavy I/O with fast devices. > > My 32-bit Core2Duo MythTV box drops audio frames without it, > but works perfectly *with* IRQBALANCE. > > My QuadCore box works very well in 32-bit mode with IRQBALANCE, > but responsiveness sucks bigtime when run in 64-bit mode (no IRQBALANCE) > during periods of multiple heavy I/O streams (USB flash drives). > > That's with both the 32 and 64 bit versions of Kubuntu Gutsy, > so the software uses pretty much identical versions either way. > > As near as I can tell, when IRQBALANCE is not configured, > all I/O device interrupts go to CPU#0. > > I don't think our CPU scheduler takes that into account when assigning > tasks to CPUs, so anything sent to CPU0 runs with very high latencies. > > Or something like that. > > Why no IRQ_BALANCE in 64-bit mode ? Have you tried running irqbalance on userspace? Checkout http://irqbalance.org/ . AFAIK CONFIG_IRQBALANCE is deprecated and eats battery power. Regards, ismail -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [EMAIL PROTECTED] created...
Tuesday 20 November 2007 Tarihinde 05:26:02 yazmıştınız: > On Monday 19 November 2007, David Miller wrote: > > From: Greg KH <[EMAIL PROTECTED]> > > Date: Mon, 19 Nov 2007 19:12:32 -0800 > > > > > Actually, if we are going to stick with this new list, can we just call > > > it "[EMAIL PROTECTED]" instead of the "-devel" stuff? > > > > Done. > > Subscribe/unsubscribe ... how? See http://vger.kernel.org/majordomo-info.html#subscription -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-usb-devel] [EMAIL PROTECTED] created...
Tuesday 20 November 2007 Tarihinde 05:26:02 yazmıştınız: On Monday 19 November 2007, David Miller wrote: From: Greg KH [EMAIL PROTECTED] Date: Mon, 19 Nov 2007 19:12:32 -0800 Actually, if we are going to stick with this new list, can we just call it [EMAIL PROTECTED] instead of the -devel stuff? Done. Subscribe/unsubscribe ... how? See http://vger.kernel.org/majordomo-info.html#subscription -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: CONFIG_IRQBALANCE for 64-bit x86 ?
Tuesday 20 November 2007 Tarihinde 06:12:21 yazmıştı: On 32-bit x86, we have CONFIG_IRQBALANCE available, but not on 64-bit x86. Why not? I ask, because this feature seems almost essential to obtaining reasonable latencies during heavy I/O with fast devices. My 32-bit Core2Duo MythTV box drops audio frames without it, but works perfectly *with* IRQBALANCE. My QuadCore box works very well in 32-bit mode with IRQBALANCE, but responsiveness sucks bigtime when run in 64-bit mode (no IRQBALANCE) during periods of multiple heavy I/O streams (USB flash drives). That's with both the 32 and 64 bit versions of Kubuntu Gutsy, so the software uses pretty much identical versions either way. As near as I can tell, when IRQBALANCE is not configured, all I/O device interrupts go to CPU#0. I don't think our CPU scheduler takes that into account when assigning tasks to CPUs, so anything sent to CPU0 runs with very high latencies. Or something like that. Why no IRQ_BALANCE in 64-bit mode ? Have you tried running irqbalance on userspace? Checkout http://irqbalance.org/ . AFAIK CONFIG_IRQBALANCE is deprecated and eats battery power. Regards, ismail -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe?
Thursday 25 October 2007 Tarihinde 17:55:00 yazmıştı: > I think the OpenBSD people decided to actually do something about this, > and I suspect it had *nothing* to do with license issues, and everything > to do with these kinds of problems. I wish them all the luck, although > personally I think LLVM is a much more interesting project. And on the LLVM side all hopes for clang [0] at least for better C++ error reporting ;-) [0] http://clang.llvm.org/ -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is gcc thread-unsafe?
Thursday 25 October 2007 Tarihinde 17:55:00 yazmıştı: I think the OpenBSD people decided to actually do something about this, and I suspect it had *nothing* to do with license issues, and everything to do with these kinds of problems. I wish them all the luck, although personally I think LLVM is a much more interesting project. And on the LLVM side all hopes for clang [0] at least for better C++ error reporting ;-) [0] http://clang.llvm.org/ -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git11 compile issues
Wednesday 17 October 2007 Tarihinde 18:33:18 yazmıştı: > Known issue ? > > > Thanks, > Badari > > CHK include/linux/version.h > CHK include/linux/utsrelease.h > CC arch/x86/kernel/asm-offsets.s > In file included from arch/x86/kernel/asm-offsets_64.c:7, > from arch/x86/kernel/asm-offsets.c:4: > include/linux/crypto.h:20:24: error: asm/atomic.h: No such file or > directory In file included from include/linux/types.h:14, Please try running make mrproper. /ismail -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-git11 compile issues
Wednesday 17 October 2007 Tarihinde 18:33:18 yazmıştı: Known issue ? Thanks, Badari CHK include/linux/version.h CHK include/linux/utsrelease.h CC arch/x86/kernel/asm-offsets.s In file included from arch/x86/kernel/asm-offsets_64.c:7, from arch/x86/kernel/asm-offsets.c:4: include/linux/crypto.h:20:24: error: asm/atomic.h: No such file or directory In file included from include/linux/types.h:14, Please try running make mrproper. /ismail -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL (updated)] kbuild updates
Wednesday 17 October 2007 Tarihinde 00:11:01 yazmıştı: [...] > Bisecting shows that: > > commit f77bf01425b11947eeb3b5b54685212c302741b8 > Author: Sam Ravnborg <[EMAIL PROTECTED](none)> > Date: Mon Oct 15 22:25:06 2007 +0200 > > kbuild: introduce ccflags-y, asflags-y and ldflags-y > > breaks booting with grub here. Grub stops with error 28: > Selected item cannot fit into memory. > > Reverting the commit fixes the problem. Same issue here. -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL (updated)] kbuild updates
Wednesday 17 October 2007 Tarihinde 00:11:01 yazmıştı: [...] Bisecting shows that: commit f77bf01425b11947eeb3b5b54685212c302741b8 Author: Sam Ravnborg [EMAIL PROTECTED](none) Date: Mon Oct 15 22:25:06 2007 +0200 kbuild: introduce ccflags-y, asflags-y and ldflags-y breaks booting with grub here. Grub stops with error 28: Selected item cannot fit into memory. Reverting the commit fixes the problem. Same issue here. -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bluetooth wireless mouse very sluggish when there is moderate network activity
s/moderated/moderate of course :-/ Saturday 13 October 2007 Tarihinde 17:13:03 yazmıştınız: > Hi all, > > I got a Bluetooth wireless mouse identifed as, > > input: Microsoft Microsoft� Wireless Notebook Presenter Mouse 8000 > as /devices/pci:00/:00:1d.1/usb3/3-1/3-1.3/3-1.3:1.0/input/input12 > input: USB HID v1.11 Mouse [Microsoft Microsoft� Wireless Notebook > Presenter Mouse 8000] on usb-:00:1d.1-1.3 > > Problem is when there is a moderate traffic on wireless interface > (300-400k/s down 50-60k/up on 4Mbit) mouse is really sluggish. This is when > I am running ktorrent. If I stop the torrent download/upload its fine > again. > > Any idea how to debug this, or why it might be happening. Btw I confirmed > this behaviour on > > kernel 2.8.18.8, 2.6.22, 2.6.23 and latest GIT tree. > > P.S: If it matters I am using ipw3945 driver with 2.6.18 kernel and iwl3945 > with the newer ones. > > Regards, > ismail -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bluetooth wireless mouse very sluggish when there is moderated network activity
Hi all, I got a Bluetooth wireless mouse identifed as, input: Microsoft Microsoft� Wireless Notebook Presenter Mouse 8000 as /devices/pci:00/:00:1d.1/usb3/3-1/3-1.3/3-1.3:1.0/input/input12 input: USB HID v1.11 Mouse [Microsoft Microsoft� Wireless Notebook Presenter Mouse 8000] on usb-:00:1d.1-1.3 Problem is when there is a moderate traffic on wireless interface (300-400k/s down 50-60k/up on 4Mbit) mouse is really sluggish. This is when I am running ktorrent. If I stop the torrent download/upload its fine again. Any idea how to debug this, or why it might be happening. Btw I confirmed this behaviour on kernel 2.8.18.8, 2.6.22, 2.6.23 and latest GIT tree. P.S: If it matters I am using ipw3945 driver with 2.6.18 kernel and iwl3945 with the newer ones. Regards, ismail -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bluetooth wireless mouse very sluggish when there is moderated network activity
Hi all, I got a Bluetooth wireless mouse identifed as, input: Microsoft Microsoft� Wireless Notebook Presenter Mouse 8000 as /devices/pci:00/:00:1d.1/usb3/3-1/3-1.3/3-1.3:1.0/input/input12 input: USB HID v1.11 Mouse [Microsoft Microsoft� Wireless Notebook Presenter Mouse 8000] on usb-:00:1d.1-1.3 Problem is when there is a moderate traffic on wireless interface (300-400k/s down 50-60k/up on 4Mbit) mouse is really sluggish. This is when I am running ktorrent. If I stop the torrent download/upload its fine again. Any idea how to debug this, or why it might be happening. Btw I confirmed this behaviour on kernel 2.8.18.8, 2.6.22, 2.6.23 and latest GIT tree. P.S: If it matters I am using ipw3945 driver with 2.6.18 kernel and iwl3945 with the newer ones. Regards, ismail -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bluetooth wireless mouse very sluggish when there is moderate network activity
s/moderated/moderate of course :-/ Saturday 13 October 2007 Tarihinde 17:13:03 yazmıştınız: Hi all, I got a Bluetooth wireless mouse identifed as, input: Microsoft Microsoft� Wireless Notebook Presenter Mouse 8000 as /devices/pci:00/:00:1d.1/usb3/3-1/3-1.3/3-1.3:1.0/input/input12 input: USB HID v1.11 Mouse [Microsoft Microsoft� Wireless Notebook Presenter Mouse 8000] on usb-:00:1d.1-1.3 Problem is when there is a moderate traffic on wireless interface (300-400k/s down 50-60k/up on 4Mbit) mouse is really sluggish. This is when I am running ktorrent. If I stop the torrent download/upload its fine again. Any idea how to debug this, or why it might be happening. Btw I confirmed this behaviour on kernel 2.8.18.8, 2.6.22, 2.6.23 and latest GIT tree. P.S: If it matters I am using ipw3945 driver with 2.6.18 kernel and iwl3945 with the newer ones. Regards, ismail -- Faith is believing what you know isn't so -- Mark Twain - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 8924] New: module speedstep-centrino does not load
On Thursday 23 August 2007 02:44:51 Andrew Morton wrote: > On Wed, 22 Aug 2007 15:12:09 -0700 (PDT) > > [EMAIL PROTECTED] wrote: > > http://bugzilla.kernel.org/show_bug.cgi?id=8924 > > > >Summary: module speedstep-centrino does not load > >Product: Drivers > >Version: 2.5 > > KernelVersion: 2.6.23-rc3 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: Other > > AssignedTo: [EMAIL PROTECTED] > > ReportedBy: [EMAIL PROTECTED] > > > > > > Most recent kernel where this bug did not occur:2.6.22 > > Distribution:gentoo > > Hardware Environment: Intel Centrino Duo, cpu family 6, model 14, Model > > Name T2300 In a Dell Inspiron 9400. > > Software Environment: i386 > > Problem Description: modprobe speedstep-centrino quits with error "no > > such device" > > same module loads successfully with older versions on the same computer. > > Steps to reproduce: > > modprobe speedstep-centrino > > I'd have thought that a lot of people would be seeing this? > > Oh well. Michal, can we please track this as a post-2.6.22 regression? Also can be reproduced on "Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz, cpu family 6, model 15" . Btw acpi-cpufreq works fine. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bugme-new] [Bug 8924] New: module speedstep-centrino does not load
On Thursday 23 August 2007 02:44:51 Andrew Morton wrote: On Wed, 22 Aug 2007 15:12:09 -0700 (PDT) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=8924 Summary: module speedstep-centrino does not load Product: Drivers Version: 2.5 KernelVersion: 2.6.23-rc3 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Most recent kernel where this bug did not occur:2.6.22 Distribution:gentoo Hardware Environment: Intel Centrino Duo, cpu family 6, model 14, Model Name T2300 In a Dell Inspiron 9400. Software Environment: i386 Problem Description: modprobe speedstep-centrino quits with error no such device same module loads successfully with older versions on the same computer. Steps to reproduce: modprobe speedstep-centrino I'd have thought that a lot of people would be seeing this? Oh well. Michal, can we please track this as a post-2.6.22 regression? Also can be reproduced on Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz, cpu family 6, model 15 . Btw acpi-cpufreq works fine. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trouble booting with new 2.6.22.3 kernel
On Tuesday 21 August 2007 22:27:25 you wrote: > On 8/21/07, Hex Star <[EMAIL PROTECTED]> wrote: > > Ah so the IDE/SATA driver should not be a module (if it is a module > > it'll cause this issue)? > > One more thing, are there any other critical kernel components that > won't work as a module and thus prevent boot? Well also the filesystem module for the root fs ( / ) should not be a module as you won't be able mount root at startup hence causing a panic. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trouble booting with new 2.6.22.3 kernel
On Tuesday 21 August 2007 22:19:13 you wrote: > Hello, I am running Kubuntu 7.04 on a mac mini (specs attached via > info.html). For learning purposes I am trying to custom build a > 2.6.22.3 kernel from source and boot from it. My plan was to use the > distributions .config file (and I specified the settings for options > that were added since the last kernel included with Kubuntu which is > (and is what I have now reverted to) Linux hexstar-desktop > 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux). > I have attached the .config file used in the building of the 2.6.22.3 > kernel. Below is the error: > > Starting up... > Uncompressing Linux... Ok, booting the kernel. > [ 32.227452] i8042.c: No controller found > [ 32.228426] Kernel panic - not syncing: VFS: Unable to mount root fs > on unknown-block(0,0) > > That is the correct block however and it is of ext3 format. I have > made sure that the ext3 module is built into the kernel and have tried > it as a module and both times I get the same error. I am not sure why > it can't find the controller? Does my controller not have support in > the latest kernel? > > Please CC me replies to this post, thanks! :) Make sure your IDE/SATA driver is compiled in unless you are using an initramfs image. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trouble booting with new 2.6.22.3 kernel
On Tuesday 21 August 2007 22:19:13 you wrote: Hello, I am running Kubuntu 7.04 on a mac mini (specs attached via info.html). For learning purposes I am trying to custom build a 2.6.22.3 kernel from source and boot from it. My plan was to use the distributions .config file (and I specified the settings for options that were added since the last kernel included with Kubuntu which is (and is what I have now reverted to) Linux hexstar-desktop 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux). I have attached the .config file used in the building of the 2.6.22.3 kernel. Below is the error: Starting up... Uncompressing Linux... Ok, booting the kernel. [ 32.227452] i8042.c: No controller found [ 32.228426] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) That is the correct block however and it is of ext3 format. I have made sure that the ext3 module is built into the kernel and have tried it as a module and both times I get the same error. I am not sure why it can't find the controller? Does my controller not have support in the latest kernel? Please CC me replies to this post, thanks! :) Make sure your IDE/SATA driver is compiled in unless you are using an initramfs image. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Trouble booting with new 2.6.22.3 kernel
On Tuesday 21 August 2007 22:27:25 you wrote: On 8/21/07, Hex Star [EMAIL PROTECTED] wrote: Ah so the IDE/SATA driver should not be a module (if it is a module it'll cause this issue)? One more thing, are there any other critical kernel components that won't work as a module and thus prevent boot? Well also the filesystem module for the root fs ( / ) should not be a module as you won't be able mount root at startup hence causing a panic. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with USB disk
On Wednesday 08 August 2007 13:48:29 you wrote: > On Tuesday 07 August 2007 23:18, Greg KH wrote: > > On Tue, Aug 07, 2007 at 10:26:15PM +0200, Niels wrote: > >> Hi, > >> > >> I'm having problems with a new 500 GB USB disk. It works, but sometimes > >> I get these in dmesg: > >> > >> > >> usb 1-3: reset high speed USB device using ehci_hcd and address 2 > >> usb 5-1: USB disconnect, address 2 > >> drivers/usb/class/usblp.c: usblp0: removed > >> sd 0:0:0:0: Device not ready: <6>: Sense Key : 0x2 [current] > >> > >> : ASC=0x4 ASCQ=0x2 > >> > >> end_request: I/O error, dev sda, sector 254148215 > >> sd 0:0:0:0: Device not ready: <6>: Sense Key : 0x2 [current] > >> > >> : ASC=0x4 ASCQ=0x2 > >> > >> end_request: I/O error, dev sda, sector 252434023 > >> EXT3-fs error (device sda1): ext3_find_entry: reading directory > >> #15761836 offset 0 > >> > >> > >> There's also a printer connected. This is on a pci/usb2 card. When the > >> above happens, I get I/O errors. When I mount the drive next, there are > >> errors and often missing files. Quite annoying! > >> > >> Kernel is 2.6.21 > >> > >> What's going on? > > > > You have a low voltage issue, or a bad cable. The device is > > electronically disconnecting itself. Try using a externally-powered > > hub, or a new cable. I am seeing a similar problem with 2.6.22 and 2.6.23-* kernels with my 60G iPod Video, works fine with 2.6.18 kernel though. Rehards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with USB disk
On Wednesday 08 August 2007 13:48:29 you wrote: On Tuesday 07 August 2007 23:18, Greg KH wrote: On Tue, Aug 07, 2007 at 10:26:15PM +0200, Niels wrote: Hi, I'm having problems with a new 500 GB USB disk. It works, but sometimes I get these in dmesg: usb 1-3: reset high speed USB device using ehci_hcd and address 2 usb 5-1: USB disconnect, address 2 drivers/usb/class/usblp.c: usblp0: removed sd 0:0:0:0: Device not ready: 6: Sense Key : 0x2 [current] : ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 254148215 sd 0:0:0:0: Device not ready: 6: Sense Key : 0x2 [current] : ASC=0x4 ASCQ=0x2 end_request: I/O error, dev sda, sector 252434023 EXT3-fs error (device sda1): ext3_find_entry: reading directory #15761836 offset 0 There's also a printer connected. This is on a pci/usb2 card. When the above happens, I get I/O errors. When I mount the drive next, there are errors and often missing files. Quite annoying! Kernel is 2.6.21 What's going on? You have a low voltage issue, or a bad cable. The device is electronically disconnecting itself. Try using a externally-powered hub, or a new cable. I am seeing a similar problem with 2.6.22 and 2.6.23-* kernels with my 60G iPod Video, works fine with 2.6.18 kernel though. Rehards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/3] 2.6.23-rc1: known regressions v3
On Monday 30 July 2007 19:33:57 you wrote: > Subject : New ACPI error/warning with Linus' latest GIT > References : http://lkml.org/lkml/2007/7/26/395 > Last known good : ? > Submitter : Ismail Dönmez <[EMAIL PROTECTED]> > Caused-By : ? > Handled-By : ? > Status : unknown This started to happen after the second ACPI merge which was for 2.6.23-rc2. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2/3] 2.6.23-rc1: known regressions v3
On Monday 30 July 2007 19:33:57 you wrote: Subject : New ACPI error/warning with Linus' latest GIT References : http://lkml.org/lkml/2007/7/26/395 Last known good : ? Submitter : Ismail Dönmez [EMAIL PROTECTED] Caused-By : ? Handled-By : ? Status : unknown This started to happen after the second ACPI merge which was for 2.6.23-rc2. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New ACPI error/warning with Linus' latest GIT
This time on a HP Pavillion DV2000 , ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62<6>ACPI: PCI Root Bridge [PCI0] (:00) ACPI: EC: Handler for query 0x57 is not found! Seems to be a new warning/error, too noisy debugging again? Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
New ACPI error/warning with Linus' latest GIT
This time on a HP Pavillion DV2000 , ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x626ACPI: PCI Root Bridge [PCI0] (:00) ACPI: EC: Handler for query 0x57 is not found! Seems to be a new warning/error, too noisy debugging again? Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Monday 23 July 2007 19:43:56 Gabriel C wrote: > I get some ACPI Exception. > > ... > > [ 33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, > Evaluating _PTC [20070126] [ 33.075437] ACPI Exception > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ > 33.075490] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, > Evaluating _PTC [20070126] [ 33.075497] ACPI Exception > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ > 33.075529] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, > Evaluating _PTC [20070126] [ 33.075536] ACPI Exception > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ > 33.075563] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, > Evaluating _PTC [20070126] [ 33.075570] ACPI Exception > (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] > Same here, I was about to blame my holy Vaio, but latest ACPI merge is to blame instead. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Monday 23 July 2007 19:43:56 Gabriel C wrote: I get some ACPI Exception. ... [ 33.075429] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 33.075437] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ 33.075490] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 33.075497] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ 33.075529] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 33.075536] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] [ 33.075563] ACPI Exception (processor_throttling-0084): AE_NOT_FOUND, Evaluating _PTC [20070126] [ 33.075570] ACPI Exception (processor_throttling-0147): AE_NOT_FOUND, Evaluating _TSS [20070126] Same here, I was about to blame my holy Vaio, but latest ACPI merge is to blame instead. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Does the kernel HPET support has problems or the hwclock from util-linux?
On Monday 02 July 2007 13:15:40 rae l wrote: > from this address, I know util-linux-2.12r is the latest: > http://www.kernel.org/pub/linux/utils/util-linux/util-linux-2.12r.lsm util-linux is now maintained @ http://userweb.kernel.org/~kzak/util-linux-ng/ /ismail -- Perfect is the enemy of good signature.asc Description: This is a digitally signed message part.
Re: Does the kernel HPET support has problems or the hwclock from util-linux?
On Monday 02 July 2007 13:15:40 rae l wrote: from this address, I know util-linux-2.12r is the latest: http://www.kernel.org/pub/linux/utils/util-linux/util-linux-2.12r.lsm util-linux is now maintained @ http://userweb.kernel.org/~kzak/util-linux-ng/ /ismail -- Perfect is the enemy of good signature.asc Description: This is a digitally signed message part.
drivers/char/mwave/3780i.c doesn't compile with gcc 4.2.0
Getting the following error : drivers/char/mwave/3780i.c: In function 'dsp3780I_EnableDSP': drivers/char/mwave/3780i.c:323: error: cannot take address of bit-field 'LoadValue' drivers/char/mwave/3780i.c:323: error: cannot take address of bit-field 'LoadValue' drivers/char/mwave/3780i.c:323: error: cannot take address of bit-field 'LoadValue' Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
drivers/char/mwave/3780i.c doesn't compile with gcc 4.2.0
Getting the following error : drivers/char/mwave/3780i.c: In function 'dsp3780I_EnableDSP': drivers/char/mwave/3780i.c:323: error: cannot take address of bit-field 'LoadValue' drivers/char/mwave/3780i.c:323: error: cannot take address of bit-field 'LoadValue' drivers/char/mwave/3780i.c:323: error: cannot take address of bit-field 'LoadValue' Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On Thursday 24 May 2007 20:38:05 Diego Calleja wrote: > El Thu, 24 May 2007 16:01:33 +0200 (CEST), Jiri Slaby <[EMAIL PROTECTED]> escribió: > > +config USB_STK11XX > > + tristate "STK11XX based webcams" > > + depends on VIDEO_V4L2 > > + ---help--- > > + This will add support for Syntek webcams such as dc1125 and stk1135. > > + > > + If you choose to build it as module, it will be called stk11xx. > > Maybe this is a too picky requeriment, but IMO it would be nice if the > module would be called "camera_stk11xx", or had any other prefix that gives > some meaning about what is doing. It's hard to decipher from the name when > you run lsmod. That would be too picky indeed since other camera modules have no camera_ prefix like pwc,spca5xx, etc. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver
On Thursday 24 May 2007 20:38:05 Diego Calleja wrote: El Thu, 24 May 2007 16:01:33 +0200 (CEST), Jiri Slaby [EMAIL PROTECTED] escribió: +config USB_STK11XX + tristate STK11XX based webcams + depends on VIDEO_V4L2 + ---help--- + This will add support for Syntek webcams such as dc1125 and stk1135. + + If you choose to build it as module, it will be called stk11xx. Maybe this is a too picky requeriment, but IMO it would be nice if the module would be called camera_stk11xx, or had any other prefix that gives some meaning about what is doing. It's hard to decipher from the name when you run lsmod. That would be too picky indeed since other camera modules have no camera_ prefix like pwc,spca5xx, etc. Regards, ismail -- Perfect is the enemy of good - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kconfig warnings on latest GIT
Hi, Following Kconfig warnings shows up with latest GIT : drivers/net/Kconfig:2279:warning: 'select' used by config symbol 'UCC_GETH' refers to undefined symbol 'UCC_FAST' drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' drivers/input/mouse/Kconfig:161:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' Regards, ismail -- Le mieux est l'ennemi du bien. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Kconfig warnings on latest GIT
Hi, Following Kconfig warnings shows up with latest GIT : drivers/net/Kconfig:2279:warning: 'select' used by config symbol 'UCC_GETH' refers to undefined symbol 'UCC_FAST' drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' drivers/input/mouse/Kconfig:161:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE' Regards, ismail -- Le mieux est l'ennemi du bien. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why ssse3?
On Thursday 03 May 2007 01:41:22 Ulrich Drepper wrote: > Note the extra 's'. We use "sse" and "sse2", but "ssse3". I assume > it's a typo. This might not be a typo see http://en.wikipedia.org/wiki/SSSE3 Regards, ismail signature.asc Description: This is a digitally signed message part.
Re: Why ssse3?
On Thursday 03 May 2007 01:41:22 Ulrich Drepper wrote: Note the extra 's'. We use sse and sse2, but ssse3. I assume it's a typo. This might not be a typo see http://en.wikipedia.org/wiki/SSSE3 Regards, ismail signature.asc Description: This is a digitally signed message part.
Re: old buffer overflow in moxa driver
On Tuesday 01 May 2007 02:04:55 Alan Cox wrote: > > I noticed that the moxa input checking security bug described by > > CVE-2005-0504 appears to remain unfixed upstream. > > > > The issue is described here: > > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504 > > > > Debian has been shipping the following patch from Andres Salomon. I > > tried contacting the listed maintainer a few months ago but received > > no response. > >case MOXA_LOAD_BIOS: > case MOXA_FIND_BOARD: > case MOXA_LOAD_C320B: > case MOXA_LOAD_CODE: > if (!capable(CAP_SYS_RAWIO)) > return -EPERM; > break; > > At the point you abuse these calls you can already just load arbitary > data from userspace anyway. So the possible exploit will only work when run by root, is that what you mean? If so isn't that still a security problem? Sorry if I misunderstood what you said. Regards, ismail signature.asc Description: This is a digitally signed message part.
Re: old buffer overflow in moxa driver
On Tuesday 01 May 2007 02:04:55 Alan Cox wrote: I noticed that the moxa input checking security bug described by CVE-2005-0504 appears to remain unfixed upstream. The issue is described here: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-0504 Debian has been shipping the following patch from Andres Salomon. I tried contacting the listed maintainer a few months ago but received no response. case MOXA_LOAD_BIOS: case MOXA_FIND_BOARD: case MOXA_LOAD_C320B: case MOXA_LOAD_CODE: if (!capable(CAP_SYS_RAWIO)) return -EPERM; break; At the point you abuse these calls you can already just load arbitary data from userspace anyway. So the possible exploit will only work when run by root, is that what you mean? If so isn't that still a security problem? Sorry if I misunderstood what you said. Regards, ismail signature.asc Description: This is a digitally signed message part.
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 14:58:54 Ingo Molnar wrote: > * Ismail Dönmez <[EMAIL PROTECTED]> wrote: > > Tested this on top of Linus' GIT tree but the system gets very > > unresponsive during high disk i/o using ext3 as filesystem but even > > writing a 300mb file to a usb disk (iPod actually) has the same > > affect. > > hm. Is this an SMP system+kernel by any chance? Nope the kernel and the system is UP. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 14:58:54 Ingo Molnar wrote: * Ismail Dönmez [EMAIL PROTECTED] wrote: Tested this on top of Linus' GIT tree but the system gets very unresponsive during high disk i/o using ext3 as filesystem but even writing a 300mb file to a usb disk (iPod actually) has the same affect. hm. Is this an SMP system+kernel by any chance? Nope the kernel and the system is UP. Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 02:23:08 Arjan van de Ven wrote: > On Mon, 2007-04-16 at 01:49 +0300, Ismail Dönmez wrote: > > Hi, > > > > On Friday 13 April 2007 23:21:00 Ingo Molnar wrote: > > > [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler > > > [CFS] > > > > > > i'm pleased to announce the first release of the "Modular Scheduler > > > Core and Completely Fair Scheduler [CFS]" patchset: > > > > > >http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.patch > > > > Tested this on top of Linus' GIT tree but the system gets very > > unresponsive during high disk i/o using ext3 as filesystem but even > > writing a 300mb file to a usb disk (iPod actually) has the same affect. > > just to make sure; this exact same workload but with the stock scheduler > does not have this effect? > > if so, then it could well be that the scheduler is too fair for it's own > good (being really fair inevitably ends up not batching as much as one > should, and batching is needed to get any kind of decent performance out > of disks nowadays) Tried with make install in kdepim (which made system sluggish with CFS) and the system is just fine (using CFQ). Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
Hi, On Friday 13 April 2007 23:21:00 Ingo Molnar wrote: > [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler > [CFS] > > i'm pleased to announce the first release of the "Modular Scheduler Core > and Completely Fair Scheduler [CFS]" patchset: > >http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.patch Tested this on top of Linus' GIT tree but the system gets very unresponsive during high disk i/o using ext3 as filesystem but even writing a 300mb file to a usb disk (iPod actually) has the same affect. Regards, ismail signature.asc Description: This is a digitally signed message part.
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
Hi, On Friday 13 April 2007 23:21:00 Ingo Molnar wrote: [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] i'm pleased to announce the first release of the Modular Scheduler Core and Completely Fair Scheduler [CFS] patchset: http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.patch Tested this on top of Linus' GIT tree but the system gets very unresponsive during high disk i/o using ext3 as filesystem but even writing a 300mb file to a usb disk (iPod actually) has the same affect. Regards, ismail signature.asc Description: This is a digitally signed message part.
Re: [Announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS]
On Monday 16 April 2007 02:23:08 Arjan van de Ven wrote: On Mon, 2007-04-16 at 01:49 +0300, Ismail Dönmez wrote: Hi, On Friday 13 April 2007 23:21:00 Ingo Molnar wrote: [announce] [patch] Modular Scheduler Core and Completely Fair Scheduler [CFS] i'm pleased to announce the first release of the Modular Scheduler Core and Completely Fair Scheduler [CFS] patchset: http://redhat.com/~mingo/cfs-scheduler/sched-modular+cfs.patch Tested this on top of Linus' GIT tree but the system gets very unresponsive during high disk i/o using ext3 as filesystem but even writing a 300mb file to a usb disk (iPod actually) has the same affect. just to make sure; this exact same workload but with the stock scheduler does not have this effect? if so, then it could well be that the scheduler is too fair for it's own good (being really fair inevitably ends up not batching as much as one should, and batching is needed to get any kind of decent performance out of disks nowadays) Tried with make install in kdepim (which made system sluggish with CFS) and the system is just fine (using CFQ). Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion
On Tuesday 20 March 2007 23:43:22 Stefan Richter wrote: > The networking subsystem has been converted from class_device to device > but ieee1394 hasn't. This results in a 100% reproducible NULL pointer > dereference if the ohci1394 driver module is unloaded while the eth1394 > module is still loaded. > http://lkml.org/lkml/2006/11/16/147 > http://lkml.org/lkml/2007/3/14/4 > > This is a regression in 2.6.21-rc1. > > Signed-off-by: Stefan Richter <[EMAIL PROTECTED]> > --- > > Works for me. I still can connect to an OS X box via eth1394 after that > and modprobe -r ohci1394 before modprobe -r eth1394 works again. > > Index: linux-2.6.21-rc4/drivers/ieee1394/eth1394.c > === > --- linux-2.6.21-rc4.orig/drivers/ieee1394/eth1394.c 2007-03-16 > 19:24:44.0 +0100 +++ > linux-2.6.21-rc4/drivers/ieee1394/eth1394.c 2007-03-20 22:28:49.0 > +0100 @@ -586,7 +586,10 @@ static void ether1394_add_host (struct h > } > > SET_MODULE_OWNER(dev); > +#if 0 > + /* FIXME - Is this the correct parent device anyway? */ > SET_NETDEV_DEV(dev, >device); > +#endif > > priv = netdev_priv(dev); This also fixes the issue for me, thanks for tracking this down Stefan. Regards. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-rc4] ieee1394: fix oops on modprobe -r ohci1394 after network class_device conversion
On Tuesday 20 March 2007 23:43:22 Stefan Richter wrote: The networking subsystem has been converted from class_device to device but ieee1394 hasn't. This results in a 100% reproducible NULL pointer dereference if the ohci1394 driver module is unloaded while the eth1394 module is still loaded. http://lkml.org/lkml/2006/11/16/147 http://lkml.org/lkml/2007/3/14/4 This is a regression in 2.6.21-rc1. Signed-off-by: Stefan Richter [EMAIL PROTECTED] --- Works for me. I still can connect to an OS X box via eth1394 after that and modprobe -r ohci1394 before modprobe -r eth1394 works again. Index: linux-2.6.21-rc4/drivers/ieee1394/eth1394.c === --- linux-2.6.21-rc4.orig/drivers/ieee1394/eth1394.c 2007-03-16 19:24:44.0 +0100 +++ linux-2.6.21-rc4/drivers/ieee1394/eth1394.c 2007-03-20 22:28:49.0 +0100 @@ -586,7 +586,10 @@ static void ether1394_add_host (struct h } SET_MODULE_OWNER(dev); +#if 0 + /* FIXME - Is this the correct parent device anyway? */ SET_NETDEV_DEV(dev, host-device); +#endif priv = netdev_priv(dev); This also fixes the issue for me, thanks for tracking this down Stefan. Regards. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)
On Thursday 15 March 2007 02:08:43 Stefan Richter wrote: [...] > > Ismail, if you have the opportunity, the next thing you could test would > be to unload eth1394 explicitly before ohci1394 on 2.6.21-rc3. This > would _not_ oops according to my observation. On a clean reboot it works as expected ; southpark cartman # rmmod eth1394 southpark cartman # rmmod ohci1394 southpark cartman # No oops. Thanks. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)
On Thursday 15 March 2007 02:08:43 Stefan Richter wrote: [...] > Ismail, if you have the opportunity, the next thing you could test would > be to unload eth1394 explicitly before ohci1394 on 2.6.21-rc3. This > would _not_ oops according to my observation. rmmod eth1394 and modprobe -r eth1394 both hangs here no oops nothing. Regards. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)
On Wednesday 14 March 2007 20:25:24 Stefan Richter wrote: > Ismail Dönmez wrote: > > On Wednesday 14 March 2007 13:14:42 Stefan Richter wrote: > >> Do you have a script or config which marks the > >> ohci1394 module to be unloaded before suspend? > > > > I used kpowersave to suspend, I failed to find anything related to > > ohci1394 in its config but rmmod ohci1394 gives exact oops so it must be > > rmmoding it. > > [...] > > > Are you able to rmmod it? > > Yes, but on 2.6.20 and earlier kernels, most of the time with > development versions of the 1394 drivers. I still haven't tried > 2.6.21-rc, will hopefully get to it tonight. Ok then that explains a bit, without suspend if I rmmod ohci1394 module I got the exact oops. Regards. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)
On Wednesday 14 March 2007 13:14:42 Stefan Richter wrote: > (Cc'ing Greg KH and linux1394-devel) > > Ismail Dönmez wrote at lkml: > > With latest GIT tree I am getting the following oops when I try to > > suspend to RAM: > > > > BUG: unable to handle kernel NULL pointer dereference at virtual address > > 0094 > > printing eip: > > c0222af4 > > *pde = > > Oops: [#1] > > PREEMPT > > Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq_dummy > > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device usbhid eth1394 > > ipw2200 ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm > > snd_timer snd snd_page_alloc tifm_7xx1 tifm_core i2c_i801 i2c_core > > ehci_hcd uhci_hcd ohci1394 ieee1394 pcmcia usbcore yenta_socket > > rsrc_nonstatic pcmcia_core sony_laptop backlight > > CPU:0 > > EIP:0060:[]Not tainted VLI > > EFLAGS: 00010246 (2.6.21-rc3 #12) > > EIP is at class_device_remove_attrs+0xa/0x30 > > eax: f7cb5b18 ebx: ecx: f8bde010 edx: > > esi: edi: f7cb5b18 ebp: esp: d93e7e1c > > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > > Process modprobe (pid: 12200, ti=d93e6000 task=e5770a50 task.ti=d93e6000) > > Stack: f7cb5b18 f7cb5b20 c0222bc3 f7cb5990 f7cb5b18 > > f7cb59c4 f8bcdc0f c0222bfb f7cb5990 f8bcdbf6 f8bd3275 04e2c100 > > 000f 03c3 f8dcf05f f7e3e000 f8bcdc17 c0220567 > > f7e3e0a4 Call Trace: > > [] class_device_del+0xa9/0xd9 > > [] __nodemgr_remove_host_dev+0x0/0xb [ieee1394] > > [] class_device_unregister+0x8/0x10 > > [] nodemgr_remove_ne+0x61/0x7a [ieee1394] > > [] ether1394_mac_addr+0x0/0x12 [eth1394] > > [] __nodemgr_remove_host_dev+0x8/0xb [ieee1394] > > [] device_for_each_child+0x1a/0x3c > > [] nodemgr_remove_host+0x30/0x90 [ieee1394] > > [] __unregister_host+0x1a/0xac [ieee1394] > > [] flush_cpu_workqueue+0x98/0xb7 > > [] highlevel_remove_host+0x21/0x42 [ieee1394] > > [] hpsb_remove_host+0x37/0x58 [ieee1394] > > [] ohci1394_pci_remove+0x47/0x1ec [ohci1394] > > [] sysfs_hash_and_remove+0xfa/0x111 > > [] pci_device_remove+0x16/0x35 > > [] __device_release_driver+0x6e/0x8b > > [] driver_detach+0x99/0xda > > [] bus_remove_driver+0x57/0x75 > > [] driver_unregister+0x8/0x13 > > [] pci_unregister_driver+0xc/0x67 > > [] sys_delete_module+0x15c/0x19d > > [] remove_vma+0x31/0x36 > > [] do_munmap+0x19b/0x1b4 > > [] sysenter_past_esp+0x5f/0x85 > > [] packet_notifier+0xf3/0x157 > > === > > Code: ff c3 85 c0 74 08 83 c0 08 e9 83 6d f6 ff b8 ea ff ff ff c3 85 c0 > > 74 08 83 c0 08 e9 4c 51 f6 ff c3 57 89 c7 56 53 8b 70 44 31 db <83> be 94 > > 00 00 00 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83 > > EIP: [] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:d93e7e1c > > > > > > Checking Google I see a similar oops was reported long ago: > > http://lkml.org/lkml/2006/11/16/147 . > > > > Any ideas/patches to test? Please CC me in your replies. > > Thanks for the report. Do you have a script or config which marks the > ohci1394 module to be unloaded before suspend? I used kpowersave to suspend, I failed to find anything related to ohci1394 in its config but rmmod ohci1394 gives exact oops so it must be rmmoding it. Also doing echo mem > /sys/power/state from konsole tries to suspend but freezes at Suspending console(s) but gives no oops. > This should not be > necessary since 2.6.21-rc1 anymore. (Although I tested this only with > APM suspend to RAM and only with the sbp2 driver as IEEE 1394 > application-layer software, and only with current 1394 drivers on top of > 2.6.20-rcX instead of 2.6.21-rcX. I heard that raw1394 survives > suspend/resume thanks to the ohci1394 updates already in 2.6.20.) Are you able to rmmod it? > But back to your problem. The older report which you pointed to was a > hickup caused by the ongoing conversion away from class_device. Further > down that discussion, a 2.6.19-rcX-mmY patch was discovered to trigger > this: http://lkml.org/lkml/2006/11/19/53 > > | the winner is... gregkh-driver-network-device.patch > > By "trigger" I mean that I don't know where the bug was, i.e. in the > then partial driver core conversion or in the ieee1394 nodemgr. > > *However*, this time it's different --- you don't have eth1394 present. Right, no firewire devices are attached. > I will boot 2.6.21-rc3 on a spare machine and see how it goes. Thanks. > As a side note, the IEEE 1394 subsystem features quite a fat usage of
Re: Ooops with suspend to RAM
On Wednesday 14 March 2007 13:50:47 Adrian Bunk wrote: > On Wed, Mar 14, 2007 at 06:42:28AM +0200, Ismail Dönmez wrote: > > Hi all, > > > > With latest GIT tree I am getting the following oops when I try to > > suspend to RAM: > >... > > Is this an old problem, or what was the last kernel that worked for you? I changed my .config totally so I'll have to check with older kernels and get back to you. I hope to try latest -mm and 2.6.20 this weekend. Thanks. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)
On Wednesday 14 March 2007 13:14:42 Stefan Richter wrote: (Cc'ing Greg KH and linux1394-devel) Ismail Dönmez wrote at lkml: With latest GIT tree I am getting the following oops when I try to suspend to RAM: BUG: unable to handle kernel NULL pointer dereference at virtual address 0094 printing eip: c0222af4 *pde = Oops: [#1] PREEMPT Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device usbhid eth1394 ipw2200 ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm snd_timer snd snd_page_alloc tifm_7xx1 tifm_core i2c_i801 i2c_core ehci_hcd uhci_hcd ohci1394 ieee1394 pcmcia usbcore yenta_socket rsrc_nonstatic pcmcia_core sony_laptop backlight CPU:0 EIP:0060:[c0222af4]Not tainted VLI EFLAGS: 00010246 (2.6.21-rc3 #12) EIP is at class_device_remove_attrs+0xa/0x30 eax: f7cb5b18 ebx: ecx: f8bde010 edx: esi: edi: f7cb5b18 ebp: esp: d93e7e1c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process modprobe (pid: 12200, ti=d93e6000 task=e5770a50 task.ti=d93e6000) Stack: f7cb5b18 f7cb5b20 c0222bc3 f7cb5990 f7cb5b18 f7cb59c4 f8bcdc0f c0222bfb f7cb5990 f8bcdbf6 f8bd3275 04e2c100 000f 03c3 f8dcf05f f7e3e000 f8bcdc17 c0220567 f7e3e0a4 Call Trace: [c0222bc3] class_device_del+0xa9/0xd9 [f8bcdc0f] __nodemgr_remove_host_dev+0x0/0xb [ieee1394] [c0222bfb] class_device_unregister+0x8/0x10 [f8bcdbf6] nodemgr_remove_ne+0x61/0x7a [ieee1394] [f8dcf05f] ether1394_mac_addr+0x0/0x12 [eth1394] [f8bcdc17] __nodemgr_remove_host_dev+0x8/0xb [ieee1394] [c0220567] device_for_each_child+0x1a/0x3c [f8bcdf34] nodemgr_remove_host+0x30/0x90 [ieee1394] [f8bcb4b1] __unregister_host+0x1a/0xac [ieee1394] [c0125e1c] flush_cpu_workqueue+0x98/0xb7 [f8bcb6da] highlevel_remove_host+0x21/0x42 [ieee1394] [f8bcb247] hpsb_remove_host+0x37/0x58 [ieee1394] [f8be1229] ohci1394_pci_remove+0x47/0x1ec [ohci1394] [c01877b9] sysfs_hash_and_remove+0xfa/0x111 [c01ccc9c] pci_device_remove+0x16/0x35 [c0222321] __device_release_driver+0x6e/0x8b [c022279b] driver_detach+0x99/0xda [c0221fa2] bus_remove_driver+0x57/0x75 [c02227fd] driver_unregister+0x8/0x13 [c01ccdfd] pci_unregister_driver+0xc/0x67 [c0134133] sys_delete_module+0x15c/0x19d [c0149fc0] remove_vma+0x31/0x36 [c014a946] do_munmap+0x19b/0x1b4 [c0104cca] sysenter_past_esp+0x5f/0x85 [c030] packet_notifier+0xf3/0x157 === Code: ff c3 85 c0 74 08 83 c0 08 e9 83 6d f6 ff b8 ea ff ff ff c3 85 c0 74 08 83 c0 08 e9 4c 51 f6 ff c3 57 89 c7 56 53 8b 70 44 31 db 83 be 94 00 00 00 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83 EIP: [c0222af4] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:d93e7e1c Checking Google I see a similar oops was reported long ago: http://lkml.org/lkml/2006/11/16/147 . Any ideas/patches to test? Please CC me in your replies. Thanks for the report. Do you have a script or config which marks the ohci1394 module to be unloaded before suspend? I used kpowersave to suspend, I failed to find anything related to ohci1394 in its config but rmmod ohci1394 gives exact oops so it must be rmmoding it. Also doing echo mem /sys/power/state from konsole tries to suspend but freezes at Suspending console(s) but gives no oops. This should not be necessary since 2.6.21-rc1 anymore. (Although I tested this only with APM suspend to RAM and only with the sbp2 driver as IEEE 1394 application-layer software, and only with current 1394 drivers on top of 2.6.20-rcX instead of 2.6.21-rcX. I heard that raw1394 survives suspend/resume thanks to the ohci1394 updates already in 2.6.20.) Are you able to rmmod it? But back to your problem. The older report which you pointed to was a hickup caused by the ongoing conversion away from class_device. Further down that discussion, a 2.6.19-rcX-mmY patch was discovered to trigger this: http://lkml.org/lkml/2006/11/19/53 | the winner is... gregkh-driver-network-device.patch By trigger I mean that I don't know where the bug was, i.e. in the then partial driver core conversion or in the ieee1394 nodemgr. *However*, this time it's different --- you don't have eth1394 present. Right, no firewire devices are attached. I will boot 2.6.21-rc3 on a spare machine and see how it goes. Thanks. As a side note, the IEEE 1394 subsystem features quite a fat usage of the driver core. We have (in order of parent devices to child devices) the host adapter's PCI device's device, the 1394 host device (hpsb_host), the node entry devices, the unit directory devices. And all of them have respective class devices. But really important outside of the ieee1394 core are only the first and the last, i.e. PCI device and unit directories. Maybe we should redesign nodemgr to work without
Re: Ooops with suspend to RAM
On Wednesday 14 March 2007 13:50:47 Adrian Bunk wrote: On Wed, Mar 14, 2007 at 06:42:28AM +0200, Ismail Dönmez wrote: Hi all, With latest GIT tree I am getting the following oops when I try to suspend to RAM: ... Is this an old problem, or what was the last kernel that worked for you? I changed my .config totally so I'll have to check with older kernels and get back to you. I hope to try latest -mm and 2.6.20 this weekend. Thanks. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)
On Wednesday 14 March 2007 20:25:24 Stefan Richter wrote: Ismail Dönmez wrote: On Wednesday 14 March 2007 13:14:42 Stefan Richter wrote: Do you have a script or config which marks the ohci1394 module to be unloaded before suspend? I used kpowersave to suspend, I failed to find anything related to ohci1394 in its config but rmmod ohci1394 gives exact oops so it must be rmmoding it. [...] Are you able to rmmod it? Yes, but on 2.6.20 and earlier kernels, most of the time with development versions of the 1394 drivers. I still haven't tried 2.6.21-rc, will hopefully get to it tonight. Ok then that explains a bit, without suspend if I rmmod ohci1394 module I got the exact oops. Regards. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)
On Thursday 15 March 2007 02:08:43 Stefan Richter wrote: [...] Ismail, if you have the opportunity, the next thing you could test would be to unload eth1394 explicitly before ohci1394 on 2.6.21-rc3. This would _not_ oops according to my observation. rmmod eth1394 and modprobe -r eth1394 both hangs here no oops nothing. Regards. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in __nodemgr_remove_host_dev (was Re: Ooops with suspend to RAM)
On Thursday 15 March 2007 02:08:43 Stefan Richter wrote: [...] Ismail, if you have the opportunity, the next thing you could test would be to unload eth1394 explicitly before ohci1394 on 2.6.21-rc3. This would _not_ oops according to my observation. On a clean reboot it works as expected ; southpark cartman # rmmod eth1394 southpark cartman # rmmod ohci1394 southpark cartman # No oops. Thanks. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Ooops with suspend to RAM
Hi all, With latest GIT tree I am getting the following oops when I try to suspend to RAM: BUG: unable to handle kernel NULL pointer dereference at virtual address 0094 printing eip: c0222af4 *pde = Oops: [#1] PREEMPT Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device usbhid eth1394 ipw2200 ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm snd_timer snd snd_page_alloc tifm_7xx1 tifm_core i2c_i801 i2c_core ehci_hcd uhci_hcd ohci1394 ieee1394 pcmcia usbcore yenta_socket rsrc_nonstatic pcmcia_core sony_laptop backlight CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.21-rc3 #12) EIP is at class_device_remove_attrs+0xa/0x30 eax: f7cb5b18 ebx: ecx: f8bde010 edx: esi: edi: f7cb5b18 ebp: esp: d93e7e1c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process modprobe (pid: 12200, ti=d93e6000 task=e5770a50 task.ti=d93e6000) Stack: f7cb5b18 f7cb5b20 c0222bc3 f7cb5990 f7cb5b18 f7cb59c4 f8bcdc0f c0222bfb f7cb5990 f8bcdbf6 f8bd3275 04e2c100 000f 03c3 f8dcf05f f7e3e000 f8bcdc17 c0220567 f7e3e0a4 Call Trace: [] class_device_del+0xa9/0xd9 [] __nodemgr_remove_host_dev+0x0/0xb [ieee1394] [] class_device_unregister+0x8/0x10 [] nodemgr_remove_ne+0x61/0x7a [ieee1394] [] ether1394_mac_addr+0x0/0x12 [eth1394] [] __nodemgr_remove_host_dev+0x8/0xb [ieee1394] [] device_for_each_child+0x1a/0x3c [] nodemgr_remove_host+0x30/0x90 [ieee1394] [] __unregister_host+0x1a/0xac [ieee1394] [] flush_cpu_workqueue+0x98/0xb7 [] highlevel_remove_host+0x21/0x42 [ieee1394] [] hpsb_remove_host+0x37/0x58 [ieee1394] [] ohci1394_pci_remove+0x47/0x1ec [ohci1394] [] sysfs_hash_and_remove+0xfa/0x111 [] pci_device_remove+0x16/0x35 [] __device_release_driver+0x6e/0x8b [] driver_detach+0x99/0xda [] bus_remove_driver+0x57/0x75 [] driver_unregister+0x8/0x13 [] pci_unregister_driver+0xc/0x67 [] sys_delete_module+0x15c/0x19d [] remove_vma+0x31/0x36 [] do_munmap+0x19b/0x1b4 [] sysenter_past_esp+0x5f/0x85 [] packet_notifier+0xf3/0x157 === Code: ff c3 85 c0 74 08 83 c0 08 e9 83 6d f6 ff b8 ea ff ff ff c3 85 c0 74 08 83 c0 08 e9 4c 51 f6 ff c3 57 89 c7 56 53 8b 70 44 31 db <83> be 94 00 00 00 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83 EIP: [] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:d93e7e1c Checking Google I see a similar oops was reported long ago: http://lkml.org/lkml/2006/11/16/147 . Any ideas/patches to test? Please CC me in your replies. Thanks. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Ooops with suspend to RAM
Hi all, With latest GIT tree I am getting the following oops when I try to suspend to RAM: BUG: unable to handle kernel NULL pointer dereference at virtual address 0094 printing eip: c0222af4 *pde = Oops: [#1] PREEMPT Modules linked in: i915 drm snd_pcm_oss snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device usbhid eth1394 ipw2200 ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm snd_timer snd snd_page_alloc tifm_7xx1 tifm_core i2c_i801 i2c_core ehci_hcd uhci_hcd ohci1394 ieee1394 pcmcia usbcore yenta_socket rsrc_nonstatic pcmcia_core sony_laptop backlight CPU:0 EIP:0060:[c0222af4]Not tainted VLI EFLAGS: 00010246 (2.6.21-rc3 #12) EIP is at class_device_remove_attrs+0xa/0x30 eax: f7cb5b18 ebx: ecx: f8bde010 edx: esi: edi: f7cb5b18 ebp: esp: d93e7e1c ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 Process modprobe (pid: 12200, ti=d93e6000 task=e5770a50 task.ti=d93e6000) Stack: f7cb5b18 f7cb5b20 c0222bc3 f7cb5990 f7cb5b18 f7cb59c4 f8bcdc0f c0222bfb f7cb5990 f8bcdbf6 f8bd3275 04e2c100 000f 03c3 f8dcf05f f7e3e000 f8bcdc17 c0220567 f7e3e0a4 Call Trace: [c0222bc3] class_device_del+0xa9/0xd9 [f8bcdc0f] __nodemgr_remove_host_dev+0x0/0xb [ieee1394] [c0222bfb] class_device_unregister+0x8/0x10 [f8bcdbf6] nodemgr_remove_ne+0x61/0x7a [ieee1394] [f8dcf05f] ether1394_mac_addr+0x0/0x12 [eth1394] [f8bcdc17] __nodemgr_remove_host_dev+0x8/0xb [ieee1394] [c0220567] device_for_each_child+0x1a/0x3c [f8bcdf34] nodemgr_remove_host+0x30/0x90 [ieee1394] [f8bcb4b1] __unregister_host+0x1a/0xac [ieee1394] [c0125e1c] flush_cpu_workqueue+0x98/0xb7 [f8bcb6da] highlevel_remove_host+0x21/0x42 [ieee1394] [f8bcb247] hpsb_remove_host+0x37/0x58 [ieee1394] [f8be1229] ohci1394_pci_remove+0x47/0x1ec [ohci1394] [c01877b9] sysfs_hash_and_remove+0xfa/0x111 [c01ccc9c] pci_device_remove+0x16/0x35 [c0222321] __device_release_driver+0x6e/0x8b [c022279b] driver_detach+0x99/0xda [c0221fa2] bus_remove_driver+0x57/0x75 [c02227fd] driver_unregister+0x8/0x13 [c01ccdfd] pci_unregister_driver+0xc/0x67 [c0134133] sys_delete_module+0x15c/0x19d [c0149fc0] remove_vma+0x31/0x36 [c014a946] do_munmap+0x19b/0x1b4 [c0104cca] sysenter_past_esp+0x5f/0x85 [c030] packet_notifier+0xf3/0x157 === Code: ff c3 85 c0 74 08 83 c0 08 e9 83 6d f6 ff b8 ea ff ff ff c3 85 c0 74 08 83 c0 08 e9 4c 51 f6 ff c3 57 89 c7 56 53 8b 70 44 31 db 83 be 94 00 00 00 00 75 09 eb 17 89 f8 e8 d7 ff ff ff 89 da 83 EIP: [c0222af4] class_device_remove_attrs+0xa/0x30 SS:ESP 0068:d93e7e1c Checking Google I see a similar oops was reported long ago: http://lkml.org/lkml/2006/11/16/147 . Any ideas/patches to test? Please CC me in your replies. Thanks. -- Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway) Ismail Donmez ismail (at) pardus.org.tr GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C Pardus Linux / KDE developer - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [patch 00/18] 2.6.18-stable review
On Wednesday 21 February 2007 19:34:45 Greg KH wrote: > On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote: > > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazmt??: > > > Responses should be made by Friday February 23 00:00 UTC. Anything > > > received after that time might be too late. > > > > We have still some CVEish patches in our package which maybe you want to > > consider adding into -stable. > > > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814 > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749 > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753 > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823 > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053 > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054 > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333 > > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006 > > Do you have a pointer to the patches for these fixes anywhere? > > And are you sure they are all for 2.6.18? The first one above is for > the 2.4 kernel tree :) Yep and Mandriva fixed that in their kernel release which is 2.6.x, I mailed [EMAIL PROTECTED] about it some time ago, but got no response so far. Regards, ismail -- FFmpeg doxy @ http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [patch 00/18] 2.6.18-stable review
On Wednesday 21 February 2007 19:34:45 Greg KH wrote: On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote: 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazmt??: Responses should be made by Friday February 23 00:00 UTC. Anything received after that time might be too late. We have still some CVEish patches in our package which maybe you want to consider adding into -stable. * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333 * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006 Do you have a pointer to the patches for these fixes anywhere? And are you sure they are all for 2.6.18? The first one above is for the 2.4 kernel tree :) Yep and Mandriva fixed that in their kernel release which is 2.6.x, I mailed [EMAIL PROTECTED] about it some time ago, but got no response so far. Regards, ismail -- FFmpeg doxy @ http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Tuesday 13 February 2007 17:10:24 Jeff Chua wrote: > On 2/13/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > > Tried this is on a patched 2.6.20 kernel with ipw3945 device and it > > always puts the card in 802.11a mode instead of 802.11bg mode. > > > > Ideas? > > Before running "iwconfig wlan0 channel 8", the card is set to > 802.11a mode. iwconfig shows rate at 54Mb/s. But after setting the > channel, it sets to 802.11b mode, and I can't find a way to change > from 11Mb/s to 54MB/s. > > "iwlist eth0 rate" only show up to 11Mb/s. > > So, my problem is the card is always in 802.11b mode. So I guess there is a common problem with a/bg modes? Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Friday 09 February 2007 23:12:42 James Ketrenos wrote: > Please hold all questions until I am done with this email. Thank you. > > We are pleased to announce the availability of a new driver for the > Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver > uses the new d80211 subsystem previously only available as part of the > wireless-dev tree. > > You can find the new driver, and additional information about it, here: > >http://intellinuxwireless.org/iwlwifi. Tried this is on a patched 2.6.20 kernel with ipw3945 device and it always puts the card in 802.11a mode instead of 802.11bg mode. Ideas? Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/acpi/ac_adapter/AC is missing after latest ACPI merge
On Tuesday 13 February 2007 07:23:15 Len Brown wrote: > On Monday 12 February 2007 13:45, Ismail Dönmez wrote: > > Hi all, > > > > After latest ACPI merge /proc/acpi/ac_adapter/AC has gone fishing : > > > > [~]> ls -al /proc/acpi/ac_adapter/ > > dr-xr-xr-x 2 root root 0 Şub 12 20:44 ADP1 > > > > [~]> ls -al /proc/acpi/ac_adapter/ADP1 > > -r--r--r-- 1 root root 0 Şub 12 20:44 state > > > > This at least breaks HAL which thinks AC is always plugged in, is this > > change intentional? > > no change intended here. It was indeed a sysfs problem which commit c2b6705b75d9c7aff98a4602a32230639e10891c fixed. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Friday 09 February 2007 23:12:42 James Ketrenos wrote: Please hold all questions until I am done with this email. Thank you. We are pleased to announce the availability of a new driver for the Intel PRO/Wireless 3945ABG Network Connection adapter. This new driver uses the new d80211 subsystem previously only available as part of the wireless-dev tree. You can find the new driver, and additional information about it, here: http://intellinuxwireless.org/iwlwifi. Tried this is on a patched 2.6.20 kernel with ipw3945 device and it always puts the card in 802.11a mode instead of 802.11bg mode. Ideas? Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] d80211 based driver for Intel PRO/Wireless 3945ABG
On Tuesday 13 February 2007 17:10:24 Jeff Chua wrote: On 2/13/07, Ismail Dönmez [EMAIL PROTECTED] wrote: Tried this is on a patched 2.6.20 kernel with ipw3945 device and it always puts the card in 802.11a mode instead of 802.11bg mode. Ideas? Before running iwconfig wlan0 channel 8, the card is set to 802.11a mode. iwconfig shows rate at 54Mb/s. But after setting the channel, it sets to 802.11b mode, and I can't find a way to change from 11Mb/s to 54MB/s. iwlist eth0 rate only show up to 11Mb/s. So, my problem is the card is always in 802.11b mode. So I guess there is a common problem with a/bg modes? Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/acpi/ac_adapter/AC is missing after latest ACPI merge
On Tuesday 13 February 2007 07:23:15 Len Brown wrote: On Monday 12 February 2007 13:45, Ismail Dönmez wrote: Hi all, After latest ACPI merge /proc/acpi/ac_adapter/AC has gone fishing : [~] ls -al /proc/acpi/ac_adapter/ dr-xr-xr-x 2 root root 0 Şub 12 20:44 ADP1 [~] ls -al /proc/acpi/ac_adapter/ADP1 -r--r--r-- 1 root root 0 Şub 12 20:44 state This at least breaks HAL which thinks AC is always plugged in, is this change intentional? no change intended here. It was indeed a sysfs problem which commit c2b6705b75d9c7aff98a4602a32230639e10891c fixed. Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/acpi/ac_adapter/AC is missing after latest ACPI merge
On Tuesday 13 February 2007 07:23:15 Len Brown wrote: > On Monday 12 February 2007 13:45, Ismail Dönmez wrote: > > Hi all, > > > > After latest ACPI merge /proc/acpi/ac_adapter/AC has gone fishing : > > > > [~]> ls -al /proc/acpi/ac_adapter/ > > dr-xr-xr-x 2 root root 0 Şub 12 20:44 ADP1 > > > > [~]> ls -al /proc/acpi/ac_adapter/ADP1 > > -r--r--r-- 1 root root 0 Şub 12 20:44 state > > > > This at least breaks HAL which thinks AC is always plugged in, is this > > change intentional? > > no change intended here. > > grep CONFIG_ACPI_AC .config > > lsmod |grep ac [~/GIT/linux-2.6]> grep CONFIG_ACPI_AC .config CONFIG_ACPI_AC=y [~/GIT/linux-2.6]> lsmod|grep ac af_packet 19976 2 cpufreq_userspace 3732 0 But it looks like older kernels had only /proc/acpi/ac_adapter/ADP1 and it worked fine with HAL, maybe something in sysfs changed? Also for some reason hal-addon-acpi doesn't seem to start at all, which might be the problem. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc/acpi/ac_adapter/AC is missing after latest ACPI merge
Hi all, After latest ACPI merge /proc/acpi/ac_adapter/AC has gone fishing : [~]> ls -al /proc/acpi/ac_adapter/ dr-xr-xr-x 2 root root 0 Şub 12 20:44 ADP1 [~]> ls -al /proc/acpi/ac_adapter/ADP1 -r--r--r-- 1 root root 0 Şub 12 20:44 state This at least breaks HAL which thinks AC is always plugged in, is this change intentional? Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc/acpi/ac_adapter/AC is missing after latest ACPI merge
Hi all, After latest ACPI merge /proc/acpi/ac_adapter/AC has gone fishing : [~] ls -al /proc/acpi/ac_adapter/ dr-xr-xr-x 2 root root 0 Şub 12 20:44 ADP1 [~] ls -al /proc/acpi/ac_adapter/ADP1 -r--r--r-- 1 root root 0 Şub 12 20:44 state This at least breaks HAL which thinks AC is always plugged in, is this change intentional? Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /proc/acpi/ac_adapter/AC is missing after latest ACPI merge
On Tuesday 13 February 2007 07:23:15 Len Brown wrote: On Monday 12 February 2007 13:45, Ismail Dönmez wrote: Hi all, After latest ACPI merge /proc/acpi/ac_adapter/AC has gone fishing : [~] ls -al /proc/acpi/ac_adapter/ dr-xr-xr-x 2 root root 0 Şub 12 20:44 ADP1 [~] ls -al /proc/acpi/ac_adapter/ADP1 -r--r--r-- 1 root root 0 Şub 12 20:44 state This at least breaks HAL which thinks AC is always plugged in, is this change intentional? no change intended here. grep CONFIG_ACPI_AC .config lsmod |grep ac [~/GIT/linux-2.6] grep CONFIG_ACPI_AC .config CONFIG_ACPI_AC=y [~/GIT/linux-2.6] lsmod|grep ac af_packet 19976 2 cpufreq_userspace 3732 0 But it looks like older kernels had only /proc/acpi/ac_adapter/ADP1 and it worked fine with HAL, maybe something in sysfs changed? Also for some reason hal-addon-acpi doesn't seem to start at all, which might be the problem. Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 18:39:27 Henrique de Moraes Holschuh wrote: > On Sat, 10 Feb 2007, Ismail Dönmez wrote: > > Hmmf looks like a userspace bug, but it certainly did work before ACPI > > update. > > Well, I don't know if this is the case here, but after reading the userland > code that people use on most applets to read /proc/acpi/ibm, I was upset > and disgusted for days. > > Some userland code *deserves* to be broken with extreme prejudice. Must be because there is no unified way to read this info ;) Userspace is honestly not guilty here. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 17:52:13 Ismail Dönmez wrote: > On Saturday 10 February 2007 14:07:13 Holger Macht wrote: > > On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: > > > On Wednesday 07 February 2007 21:18:50 Len Brown wrote: > > > > Hi Linus, > > > > > > > > please pull from: > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > > > release > > > > > > > > ACPICA Core version 2070126 simplifies the ACPI table manager > > > > code by consolidating multiple table definitions into one. > > > > It also saves memory by mapping the tables where the BIOS provides > > > > them rather than copying them into the kernel. > > > > > > This breaks kpowersave, now it always says laptop is plugged in and > > > does not show any battery status. Any /proc changes in this release? > > > > kpowersave just reflects what HAL thinks, and HAL reflects what the > > kernel thinks. So please post the content of > > /proc/acpi/ac_adapter/AC/state when AC is not plugged in to figure out if > > it's just a userland bug or a kernel issue. > > [~]> cat /proc/acpi/ac_adapter/ADP1/state > state: off-line > > > Hmmf looks like a userspace bug, but it certainly did work before ACPI > update. Hmm whats this ADP1 and there is no /proc/acpi/ac_adapter/AC around... Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 14:07:13 Holger Macht wrote: > On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: > > On Wednesday 07 February 2007 21:18:50 Len Brown wrote: > > > Hi Linus, > > > > > > please pull from: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > > > release > > > > > > ACPICA Core version 2070126 simplifies the ACPI table manager > > > code by consolidating multiple table definitions into one. > > > It also saves memory by mapping the tables where the BIOS provides them > > > rather than copying them into the kernel. > > > > This breaks kpowersave, now it always says laptop is plugged in and does > > not show any battery status. Any /proc changes in this release? > > kpowersave just reflects what HAL thinks, and HAL reflects what the kernel > thinks. So please post the content of /proc/acpi/ac_adapter/AC/state when > AC is not plugged in to figure out if it's just a userland bug or a kernel > issue. [~]> cat /proc/acpi/ac_adapter/ADP1/state state: off-line Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Wednesday 07 February 2007 21:18:50 Len Brown wrote: > Hi Linus, > > please pull from: > > git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git > release > > ACPICA Core version 2070126 simplifies the ACPI table manager > code by consolidating multiple table definitions into one. > It also saves memory by mapping the tables where the BIOS provides them > rather than copying them into the kernel. This breaks kpowersave, now it always says laptop is plugged in and does not show any battery status. Any /proc changes in this release? Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Wednesday 07 February 2007 21:18:50 Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release ACPICA Core version 2070126 simplifies the ACPI table manager code by consolidating multiple table definitions into one. It also saves memory by mapping the tables where the BIOS provides them rather than copying them into the kernel. This breaks kpowersave, now it always says laptop is plugged in and does not show any battery status. Any /proc changes in this release? Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 14:07:13 Holger Macht wrote: On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: On Wednesday 07 February 2007 21:18:50 Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release ACPICA Core version 2070126 simplifies the ACPI table manager code by consolidating multiple table definitions into one. It also saves memory by mapping the tables where the BIOS provides them rather than copying them into the kernel. This breaks kpowersave, now it always says laptop is plugged in and does not show any battery status. Any /proc changes in this release? kpowersave just reflects what HAL thinks, and HAL reflects what the kernel thinks. So please post the content of /proc/acpi/ac_adapter/AC/state when AC is not plugged in to figure out if it's just a userland bug or a kernel issue. [~] cat /proc/acpi/ac_adapter/ADP1/state state: off-line Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 17:52:13 Ismail Dönmez wrote: On Saturday 10 February 2007 14:07:13 Holger Macht wrote: On Sat 10. Feb - 10:27:14, Ismail Dönmez wrote: On Wednesday 07 February 2007 21:18:50 Len Brown wrote: Hi Linus, please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git release ACPICA Core version 2070126 simplifies the ACPI table manager code by consolidating multiple table definitions into one. It also saves memory by mapping the tables where the BIOS provides them rather than copying them into the kernel. This breaks kpowersave, now it always says laptop is plugged in and does not show any battery status. Any /proc changes in this release? kpowersave just reflects what HAL thinks, and HAL reflects what the kernel thinks. So please post the content of /proc/acpi/ac_adapter/AC/state when AC is not plugged in to figure out if it's just a userland bug or a kernel issue. [~] cat /proc/acpi/ac_adapter/ADP1/state state: off-line Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Hmm whats this ADP1 and there is no /proc/acpi/ac_adapter/AC around... Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] ACPI patches for 2.6.21
On Saturday 10 February 2007 18:39:27 Henrique de Moraes Holschuh wrote: On Sat, 10 Feb 2007, Ismail Dönmez wrote: Hmmf looks like a userspace bug, but it certainly did work before ACPI update. Well, I don't know if this is the case here, but after reading the userland code that people use on most applets to read /proc/acpi/ibm, I was upset and disgusted for days. Some userland code *deserves* to be broken with extreme prejudice. Must be because there is no unified way to read this info ;) Userspace is honestly not guilty here. Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [NET] dmfe : number of fixes and features
Hi, On Wednesday 07 February 2007 19:57:21 you wrote: > Hello, > > Before some time I decided to fix suspend/resume on my Davicom network > card. During development I also fixed couple of bugs and added support for > link detection and WOL Note : 2.6.20 already has support for link detection > , but it is broken when card has external PHY , like mine. > > So here it goes: > > [PATCH] [NET] [001] dmfe : trivial/spelling fixes > [PATCH] [NET] [002] dmfe : Fix possible oops > [PATCH] [NET] [003] dmfe : fix link detection > [PATCH] [NET] [004] dmfe : Add suspend/resume support > [PATCH] [NET] [005] dmfe : Add support for wake-on-lan CC netdev@vger.kernel.org for network patches. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [NET] dmfe : number of fixes and features
Hi, On Wednesday 07 February 2007 19:57:21 you wrote: Hello, Before some time I decided to fix suspend/resume on my Davicom network card. During development I also fixed couple of bugs and added support for link detection and WOL Note : 2.6.20 already has support for link detection , but it is broken when card has external PHY , like mine. So here it goes: [PATCH] [NET] [001] dmfe : trivial/spelling fixes [PATCH] [NET] [002] dmfe : Fix possible oops [PATCH] [NET] [003] dmfe : fix link detection [PATCH] [NET] [004] dmfe : Add suspend/resume support [PATCH] [NET] [005] dmfe : Add support for wake-on-lan CC netdev@vger.kernel.org for network patches. Regards, ismail - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ipw2200 problem with 2.6.20-rc6
Hi, I recently saw this in dmesg after the wireless network suddenly stopped working and after some time it worked again: ipw2200/0: page allocation failure. order:0, mode:0x20 [] __alloc_pages+0x27b/0x28c [] cache_alloc_refill+0x292/0x46f [] __kmalloc+0x45/0x51 [] __alloc_skb+0x47/0x102 [] ipw_rx_queue_replenish+0x52/0xf0 [ipw2200] [] __sched_text_start+0x4c3/0x560 [] ipw_bg_rx_queue_replenish+0x1e/0x27 [ipw2200] [] run_workqueue+0x8f/0x14b [] ipw_bg_rx_queue_replenish+0x0/0x27 [ipw2200] [] worker_thread+0x108/0x132 [] default_wake_function+0x0/0xc [] worker_thread+0x0/0x132 [] kthread+0xa0/0xc8 [] kthread+0x0/0xc8 [] kernel_thread_helper+0x7/0x10 === Mem-info: DMA per-cpu: CPU0: Hot: hi:0, btch: 1 usd: 0 Cold: hi:0, btch: 1 usd: 0 Normal per-cpu: CPU0: Hot: hi: 186, btch: 31 usd: 30 Cold: hi: 62, btch: 15 usd: 56 Active:96632 inactive:5235 dirty:3532 writeback:4 unstable:0 free:730 slab:7772 mapped:23842 pagetables:958 DMA free:1968kB min:88kB low:108kB high:132kB active:10068kB inactive:0kB present:16256kB pages_scanned:247 all_unreclaimable? no lowmem_reserve[]: 0 483 483 Normal free:952kB min:2764kB low:3452kB high:4144kB active:376460kB inactive:20940kB present:494668kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 DMA: 0*4kB 0*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1968kB Normal: 0*4kB 1*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 952kB Swap cache: add 57, delete 57, find 0/0, race 0+0 Free swap = 614164kB Total swap = 614392kB Free swap: 614164kB 128736 pages of RAM 0 pages of HIGHMEM 2010 reserved pages 127625 pages shared 0 pages swap cached 3532 pages dirty 4 pages writeback 23842 pages mapped 7772 pages slab 958 pages pagetables eth2: Can not allocate SKB buffers. Regards, ismail - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
