Re: [PATCH 2/2] ASLR: add possibility for more fine-grained tweaking

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2

[Ismail Dönmez]

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?

[Ismail Dönmez]

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?

[Ismail Dönmez]

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?

[Ismail Dönmez]

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: CONFIG_IRQBALANCE for 64-bit x86 ?

[Ismail Dönmez]

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

[Ismail Dönmez]

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: Is gcc thread-unsafe?

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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: Problems with USB disk

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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/

Re: Linus 2.6.23-rc1

[Ismail Dönmez]

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?

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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?

[Ismail Dönmez]

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

[Ismail Dönmez]

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]

[Ismail Dönmez]

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]

[Ismail Dönmez]

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]

[Ismail Dönmez]

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: [PATCH 2.6.21-rc4] ieee1394: fix oops on "modprobe -r ohci1394" after network class_device conversion

[Ismail Dönmez]

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)

[Ismail Dönmez]

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)

[Ismail Dönmez]

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)

[Ismail Dönmez]

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)

[Ismail Dönmez]

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 

Re: Ooops with suspend to RAM

[Ismail Dönmez]

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/

Ooops with suspend to RAM

[Ismail Dönmez]

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/

Re: [stable] [patch 00/18] 2.6.18-stable review

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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: [GIT PATCH] ACPI patches for 2.6.21

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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

[Ismail Dönmez]

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: [PATCH] [NET] dmfe : number of fixes and features

[Ismail Dönmez]

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

[Ismail Dönmez]

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/

Re: Abysmal disk performance, how to debug?

[Ismail Dönmez]

20 Oca 2007 Cts 22:10 tarihinde, Tim Schmielau şunları yazmıştı: 
[...]
>
> Note that these dd "benchmarks" are completely bogus, because the data=20
> doesn't actually get written to disk in that time. For some enlightening=20
> data, try
>
>   time dd if=3D/dev/zero of=3D/tmp/1GB bs=3D1M count=3D1024; time sync
>
> The dd returns as soon as all data could be buffered in RAM. Only sync=20
> will show how long it takes to actually write out the data to disk.
> also explains why you see better results is writeout starts earlier.

Still not that bad:

[~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024;sync
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 53,3194 s, 20,1 MB/s

real0m53.517s
user0m0.003s
sys 0m3.193s

-
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: Abysmal disk performance, how to debug?

[Ismail Dönmez]

20 Oca 2007 Cts 22:05 tarihinde, Willy Tarreau şunları yazmıştı: 
> On Sun, Jan 21, 2007 at 01:14:41AM +0530, Sunil Naidu wrote:
> > On 1/20/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
[...]
> It should not have changed the throughput at all if the
> hardware was not a bit strange (well, it's a VAIO after all, I've
> had one too, fortunately it died one month after the warranty,
> putting an end to all my problems...).

How true is this, VAIO sucks on Linux :'(

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: Abysmal disk performance, how to debug?

[Ismail Dönmez]

20 Oca 2007 Cts 20:03 tarihinde şunları yazmıştınız:
> On Sat, Jan 20, 2007 at 07:52:53PM +0200, Ismail Dönmez wrote:
> > 20 Oca 2007 Cts 19:45 tarihinde ??unlar?? yazmt??n??z:
> > [...]
> >
> > > > vaio cartman # hdparm -tT /dev/hda
> > > >
> > > > /dev/hda:
> > > >  Timing cached reads:   1576 MB in  2.00 seconds = 788.18 MB/sec
> > > >  Timing buffered disk reads:   74 MB in  3.01 seconds =  24.55 MB/sec
> > > >
> > > >
> > > > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > > > 1024+0 records in
> > > > 1024+0 records out
> > > > 1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s
> > > >
> > > > real1m17.482s
> > > > user0m0.003s
> > > > sys 0m2.350s
> > >
> > > That's not bad at all ! I suspect that if your system becomes
> > > unresponsive, it's because real writes start when the cache is full.
> > > And if you fill 512 MB of RAM with data that you then need to flush on
> > > disk at 14 MB/s, it can take about 40 seconds during which it might be
> > > difficult to do anything.
> > >
> > > Try lowering the cache flush starting point to about 10 MB if you want
> > > (2% of 512 MB) :
> > >
> > > # echo 2 >/proc/sys/vm/dirty_ratio
> > > # echo 2 >/proc/sys/vm/dirty_background_ratio
> >
> > After that I get,
> >
> > [~]>  time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > 1024+0 records in
> > 1024+0 records out
> > 1073741824 bytes (1,1 GB) copied, 41,7005 s, 25,7 MB/s
> >
> > real0m41.926s
> > user0m0.007s
> > sys 0m2.500s
> >
> >
> > not bad! thanks :)
>
> It is not expected to increase write performance, but it should help
> you do something else during that time, or also give more responsiveness
> to Ctrl-C. It is possible that you have fast and slow RAM, or that your
> video card uses shared memory which slows down some parts of memory
> which are not used anymore with those parameters.

Thanks I will try to upgrade RAM but for now at least responsiveness seems to 
be better.

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: Abysmal disk performance, how to debug?

[Ismail Dönmez]

20 Oca 2007 Cts 19:45 tarihinde şunları yazmıştınız:
[...]
> > vaio cartman # hdparm -tT /dev/hda
> >
> > /dev/hda:
> >  Timing cached reads:   1576 MB in  2.00 seconds = 788.18 MB/sec
> >  Timing buffered disk reads:   74 MB in  3.01 seconds =  24.55 MB/sec
> >
> >
> > [~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
> > 1024+0 records in
> > 1024+0 records out
> > 1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s
> >
> > real1m17.482s
> > user0m0.003s
> > sys 0m2.350s
>
> That's not bad at all ! I suspect that if your system becomes unresponsive,
> it's because real writes start when the cache is full. And if you fill
> 512 MB of RAM with data that you then need to flush on disk at 14 MB/s, it
> can take about 40 seconds during which it might be difficult to do
> anything.
>
> Try lowering the cache flush starting point to about 10 MB if you want
> (2% of 512 MB) :
>
> # echo 2 >/proc/sys/vm/dirty_ratio
> # echo 2 >/proc/sys/vm/dirty_background_ratio

After that I get,

[~]>  time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 41,7005 s, 25,7 MB/s

real0m41.926s
user0m0.007s
sys 0m2.500s


not bad! thanks :)

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/

Abysmal disk performance, how to debug?

[Ismail Dönmez]

Hi all,

I own a Sony Vaio VGN-FS285B and disk performance to say at least is very very 
slow. Writing 1 GB data makes the laptop unresponsive. Here is some data 
identifying the drive. Hope someone can tell me how to debug and find out 
whats the problem.

FWIW since 2.6.16 the problem is same and I didn't test with 2.4 kernels. Here 
is some data. And I tested with xfs & ext3. Both slow slow disk writes.

vaio cartman # hdparm /dev/hda

/dev/hda:
 multcount= 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq=  1 (on)
 using_dma=  1 (on)
 keepsettings =  0 (off)
 readonly =  0 (off)
 readahead= 256 (on)
 geometry = 65535/16/63, sectors = 156301488, start = 0
vaio cartman # hdparm -i /dev/hda

/dev/hda:

 Model=FUJITSU MHV2080AT, FwRev=0096, SerialNo=NS56T58270LE
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=0
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=156301488
 IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4
 DMA modes:  mdma0 mdma1 mdma2
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma3 udma4 *udma5
 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:  ATA/ATAPI-2 
ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6

 * signifies the current active mode


vaio cartman # hdparm -tT /dev/hda

/dev/hda:
 Timing cached reads:   1576 MB in  2.00 seconds = 788.18 MB/sec
 Timing buffered disk reads:   74 MB in  3.01 seconds =  24.55 MB/sec


[~]> time dd if=/dev/zero of=/tmp/1GB bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB) copied, 77,2809 s, 13,9 MB/s

real1m17.482s
user0m0.003s
sys 0m2.350s


dmesg follows:


 PTL  0x005f) @ 0x1f6e9e78
ACPI: FADT (v002   Sony   J1 0x20050311 PTL  0x005f) @ 0x1f6e9ee0
ACPI: BOOT (v001   Sony   J1 0x20050311 PTL  0x0001) @ 0x1f6e9fd8
ACPI: MCFG (v001   Sony   J1 0x20050311 PTL  0x005f) @ 0x1f6e9f9c
ACPI: SSDT (v001   Sony   J1 0x20050311 PTL  0x20030224) @ 0x1f6e618f
ACPI: SSDT (v001   Sony   J1 0x20050311 PTL  0x20030224) @ 0x1f6e5d4a
ACPI: SSDT (v001   Sony   J1 0x20050311 PTL  0x20030224) @ 0x1f6e5b2f
ACPI: SSDT (v001   Sony   J1 0x20050311 PTL  0x20030224) @ 0x1f6e5916
ACPI: DSDT (v001   Sony   J1 0x20050311 PTL  0x20030224) @ 0x
ACPI: PM-Timer IO Port: 0x1008
Allocating PCI resources starting at 3000 (gap: 2000:c000)
Detected 1792.955 MHz processor.
Built 1 zonelists.  Total pages: 127731
Kernel command line: root=/dev/hda1 vga=791 mudur=language:tr
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 506696k/514944k available (2242k kernel code, 7824k reserved, 734k 
data, 176k init, 0k highmem)
virtual kernel memory layout:
fixmap  : 0xfffeb000 - 0xf000   (  80 kB)
pkmap   : 0xff80 - 0xffc0   (4096 kB)
vmalloc : 0xe000 - 0xff7fe000   ( 503 MB)
lowmem  : 0xc000 - 0xdf6e   ( 502 MB)
  .init : 0xc03ec000 - 0xc0418000   ( 176 kB)
  .data : 0xc033099f - 0xc03e850c   ( 734 kB)
  .text : 0xc010 - 0xc033099f   (2242 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3462.00 BogoMIPS 
(lpj=5768004)
Security Framework v1.0.0 initialized
Mount-cache hash table entries: 512
CPU: After generic identify, caps: afe9fbff 0010   
0180  
CPU: L1 I cache: 32K, L1 D cache: 32K
CPU: L2 cache: 2048K
CPU: After all inits, caps: afe9fbff 0010  2040 0180 
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to e000.
CPU: Intel(R) Pentium(R) M processor 1.73GHz stepping 08
Checking 'hlt' instruction... OK.
ACPI: Core revision 20060707
ACPI: setting ELCR to 0200 (from 0cb8)
NET: Registered protocol family 16
No dock devices found.
ACPI: bus type pci registered
PCI: Using MMCONFIG
Setting up standard PCI resources
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
Boot video device is :00:02.0
PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
PCI quirk: region 1180-11bf claimed by ICH6 GPIO
PCI: Firmware left :06:08.0 e100 interrupts enabled, disabling
PCI: Transparent bridge - :00:1e.0
PCI: Bus #07 (-#0a) is hidden behind transparent bridge #06 (-#07) 
(try 'pci=assign-busses')
Please report the result to linux-kernel to fix this permanently
ACPI: PCI In

Re: 2.6.20-rc2: known unfixed regressions (v2)

[Ismail Dönmez]

31 Ara 2006 Paz 02:47 tarihinde, Adrian Bunk şunları yazmıştı: 
[...]
> Subject: ALSA: No sound in KDE with intel hda
> References : http://lkml.org/lkml/2006/12/30/73
> Submitter  : Ismail Dönmez <[EMAIL PROTECTED]>
> Status : unknown

Just tried with 2.6.18.6 and aRts still have no sound, there must be something 
else broken on my side.

Thanks,
ismail

-- 
2 + 2 = 5 for very large values of 2
-
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: No sound in KDE with intel hda since 2.6.20-rc1

[Ismail Dönmez]

30 Ara 2006 Cts 22:45 tarihinde, Michael S. Tsirkin şunları yazmıştı: 
> > > > > > Virtual MIDI Card 1
> > > > >
> > > > > Compile this feature out, I bet things start working again.
> > > >
> > > > Yes, this helped, thanks.
> > > > BTW, is this expected?
> > >
> > > It's a severe "misfeature" in my opinion that caused me problems years
> > > ago. The first soundcard becomes "default", which can probably be
> > > overridden in many different ways.
> > >
> > > However, I really think a hack should be put in to prevent "virtual
> > > MIDI" from ever being in the first slot, it's just a bug asking to
> > > happen.
> >
> > So should we enable Virtual MIDI in kernel config? Since I have it off
> > and aRts have no sound with ALSA backend.
>
> Try updating to latest git - I have
> 7479b1ce5ea41a828002c60739cff37f47b62913 with Virtual MIDI off and ALSA
> seems to work.
>
> BTW, Amarok has an Engine dialog where you can easily switch between
> backends which is good for testing.

Still no sound with latest git. But Amarok with ALSA backend works fine. Maybe 
some other problem with aRts. Not sure yet but this is surely a new breakage.

Regards,
ismail
-- 
2 + 2 = 5 for very large values of 2
-
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: No sound in KDE with intel hda since 2.6.20-rc1

[Ismail Dönmez]

30 Ara 2006 Cts 21:19 tarihinde şunları yazmıştınız:
> On Saturday 30 December 2006 19:11, Michael S. Tsirkin wrote:
> > > On Friday 29 December 2006 06:25, Michael S. Tsirkin wrote:
> > > > Virtual MIDI Card 1
> > >
> > > Compile this feature out, I bet things start working again.
> >
> > Yes, this helped, thanks.
> > BTW, is this expected?
>
> It's a severe "misfeature" in my opinion that caused me problems years ago.
> The first soundcard becomes "default", which can probably be overridden in
> many different ways.
>
> However, I really think a hack should be put in to prevent "virtual MIDI"
> from ever being in the first slot, it's just a bug asking to happen.

So should we enable Virtual MIDI in kernel config? Since I have it off and 
aRts have no sound with ALSA backend.

Regards,
ismail

-- 
2 + 2 = 5 for very large values of 2
-
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: No sound in KDE with intel hda since 2.6.20-rc1

[Ismail Dönmez]

29 Ara 2006 Cum 09:18 tarihinde, Michael S. Tsirkin şunları yazmıştı: 
> > Since 2.6.20-rc1 (tested both -rc1 and rc2), system notification sounds
> > under KDE, and sound in games (e.g. TuxPaint) no longer seem to work on
> > my T60 thinkpad. Works fine under 2.6.19 though.  The strange thing is
> > e.g. Amarok still plays music fine.
>
> Tis is on Kubuntu 6.06, BTW.

Same on Pardus 2007 which uses KDE 3.5.5.

Regards,
ismail

-- 
2 + 2 = 5 for very large values of 2
-
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: ACPI EC warnings

[Ismail Dönmez]

24 Ara 2006 Paz 23:19 tarihinde, Guillaume Chazarain şunları yazmıştı: 
> > Patch looks nice,
>
> But LKML didn't like gmail's HTML so here is it again. Hopefully this
> one will pass.

I think this one didn't pass either :-/

> > btw do you notice any skippy behaviour? i.e sound skips when
> > I get this warning
>
> No, in my case I just get the message: ACPI: EC: evaluating _Q20
>
> > or something else is broken and I blame ACPI because its
> > flooding dmesg =)
>
> I happen to have at the moment some other debugging printk, flooding
> my logs, and sound doesn't skip either :-) Asus V6VA - Pentium-M 2GHz here.

Yeah the warning seems unrelated to skips.

Regards,
ismail

-- 
2 + 2 = 5 for very large values of 2
-
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: ACPI EC warnings

[Ismail Dönmez]

24 Ara 2006 Paz 23:02 tarihinde, Guillaume Chazarain şunları yazmıştı: 
> 2006/12/24, Ismail Donmez <[EMAIL PROTECTED]>:
> > ACPI: EC: evaluating _Q60
>
> Same thing here, I think it is caused by
> http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=comm
>it;h=af3fd1404fd4f0f58ebbb52b22be4f1ca0794cda
>
> The attached patch restores the previous behaviour.

Patch looks nice, btw do you notice any skippy behaviour? i.e sound skips when 
I get this warning or something else is broken and I blame ACPI because its 
flooding dmesg =)

Regards,
ismail

-- 
2 + 2 = 5 for very large values of 2
-
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: NForce4 ide problems?

[ismail dönmez]

Hi,

On 4/20/05, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> You might want to post that Oops message if you want someone to try and 
> fix it.
> 

Ok see it below.

> Also, from your dmesg output I see that you are loading the NVIDIA module
>  NVRM: loading NVIDIA Linux x86_64 NVIDIA Kernel Module  1.0-7174  Tue Mar
> 22 06:45:40 PST 2005
> You may want to try /not/ loading that module and then reproduce the 
> kernel panic and then post that Oops or panic message instead.
> 
Ok this message was taken without loading nvidia module.

I get this just after hdparm command on /dev/hda :


CPU 0: Machine Check Exception: 4 Bank 4: b2070f0f
TSC 1cb2201501c
Kernel panic - not syncing : Machine check



Any help is appreciated.

Regards,
ismail


-- 
Time is what you make of it
-
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/

NForce4 ide problems?

[ismail dönmez]

Hi all,

I recently bought an Asus A8N-SLI mobo and an AMD 3500+ CPU for my
system but my ide drive seems to have some problems with them. Here is
what I get at boot :


hda: 156368016 sectors (80060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
 /dev/ide/host0/bus0/target0/lun0:hda: dma_intr: status=0x51 {
DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown
hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
ide: failed opcode was: unknown


First I thought it was bad ide cable ( because I wasn't using the one
that came with mobo ) so I tried with the brand new cable coming with
mobo and same error happened. Also trying to do something like :

hdparm -m16 -c -u1 -d1 -Xudma2 /dev/hda

results in a cpu exception thrown and a kernel panic after that. Full
dmesg log is attached. I appreciate any help/comments.

P.S: I tried with kernel 2.6.10 and 2.6.12-rc2 and same problems happen

Regards,
ismail


-- 
Time is what you make of it
Bootdata ok (command line is [EMAIL PROTECTED] ro root=307)
Linux version 2.6.12-rc2 ([EMAIL PROTECTED]) (gcc version 4.0.0 20050413 
(prerelease) (Debian 4.0-0pre11)) #3 Wed Apr 20 17:07:40 EEST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009f800 (usable)
 BIOS-e820: 0009f800 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 3fff (usable)
 BIOS-e820: 3fff - 3fff3000 (ACPI NVS)
 BIOS-e820: 3fff3000 - 4000 (ACPI data)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - fec01000 (reserved)
 BIOS-e820: fee0 - fef0 (reserved)
 BIOS-e820: fefffc00 - ff00 (reserved)
 BIOS-e820:  - 0001 (reserved)
ACPI: RSDP (v000 Nvidia) @ 0x000f74b0
ACPI: RSDT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x3fff3000
ACPI: FADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x3fff3040
ACPI: MCFG (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x3fff9280
ACPI: MADT (v001 Nvidia AWRDACPI 0x42302e31 AWRD 0x) @ 
0x3fff9200
ACPI: DSDT (v001 NVIDIA AWRDACPI 0x1000 MSFT 0x010e) @ 
0x
On node 0 totalpages: 262128
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 258032 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
Nvidia board detected. Ignoring ACPI timer override.
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:7 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, version 17, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: BIOS IRQ0 pin2 override ignored.
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge)
ACPI: IRQ9 used by override.
ACPI: IRQ14 used by override.
ACPI: IRQ15 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Built 1 zonelists
Kernel command line: [EMAIL PROTECTED] ro root=307 console=tty0
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 131072 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 2211.359 MHz processor.
Console: colour dummy device 80x25
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 1026920k/1048512k available (1908k kernel code, 20892k reserved, 955k 
data, 132k init)
Calibrating delay loop... 4374.52 BogoMIPS (lpj=2187264)
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: AMD Athlon(tm) 64 Processor 3500+ stepping 0a
Using local APIC NMI watchdog using perfctr0
Using local APIC timer interrupts.
Detected 12.564 MHz APIC timer.
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050309
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
PCI: Transparent bridge - :00:09.0
Boot video device is :01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 7 9 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 7 9 10 11 12 14 15) *0, di

Re: 2.6.11.x: bootprompt: ALSA: no soundcard detected

[ismail dönmez]

That means you didn't load the correct module for your soundcard.


On Sun, 10 Apr 2005 10:16:49 +, Dennis Heuer <[EMAIL PROTECTED]> wrote:
> This doesn't help. Alsamixer prints:
> 
> failure in snd_ctl_open: no such device
> 
> Dennis

-- 
Time is what you make of it
-
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.11: CDROM_SEND_PACKET as non-root?

[ismail dönmez]

growisofs works as a non-root user here.


On Fri, 18 Mar 2005 15:45:46 +0100, Martin Zwickel
<[EMAIL PROTECTED]> wrote:
> Hi all!
> 
> I have a small question:
> What do I have to do, to let the ioctl CDROM_SEND_PACKET work as a
> non-root user under 2.6.11?
> 
> I try to burn a DVD with growisofs as a non-root user without success.
> 
> I know that there were some changes about access restriction (since
> 2.6.8), but I haven't found anything to get a clue about the current
> status.
> 
> So is it just impossible to send a packet to the DVD burner without root
> access? Do I have to use a wrapper that sets the effective user id to
> root and then runs growisofs?
> 
> 
> It's friday, so sorry for that stupid question, but a comment on that
> would be fine :)
> 
> Regards,
> Martin
> 
> -- 
> MyExcuse:
> Recursive traversal of loopback mount points
> 
> Martin Zwickel <[EMAIL PROTECTED]>
> Research & Development
> 
> TechnoTrend AG 
> 
> 

-- 
Time is what you make of it
-
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/