Re: [PATCH v2] scripts/setlocalversion: make git describe output more reliable

[Nico Schottelius]

Hey Rasmus,

Rasmus Villemoes  writes:
>> So I suggest you introduce something on the line of:
>>
>> ...
>> num_chars=12
>> ...
>> --abbrev=$num_chars
>
> I considered that, but it becomes quite ugly since it needs to get into
> the awk script (as a 13, though perhaps we could get awk to do the +1, I
> don't really speak awk), where we'd then need to use " instead of ' and
> then escape the $ that are to be interpreted by awk and not the shell.

No need for that, awk can read (and use) environment variables...

> So I think it's more readable with hardcoding and comments explaining
> why they are there; should anyone ever want to change 12.

... so that in practice you only need to change 13 to var+1 and 12 to $var.

Cheers,

Nico


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

Re: [PATCH v2] scripts/setlocalversion: make git describe output more reliable

[Nico Schottelius]

Thanks for the patch Rasmus. Overall it looks good to me, be aligned to
the stable patch submission rules makes sense. A tiny thing though:

I did not calculate the exact collision probability with 12 characters
and it does not make sense to even discuss this, if this is a current
rule for stable patches. However we have a couple of 12's scattered in
the code. And if the submission rule changes in the future, we should
have a single location to update it.

So I suggest you introduce something on the line of:

...
num_chars=12
...
--abbrev=$num_chars
...

I guess you get the picture.

Greetings from the sunny mountains,

Nico


Rasmus Villemoes  writes:

> When building for an embedded target using Yocto, we're sometimes
> observing that the version string that gets built into vmlinux (and
> thus what uname -a reports) differs from the path under /lib/modules/
> where modules get installed in the rootfs, but only in the length of
> the -gabc123def suffix. Hence modprobe always fails.
>
> The problem is that Yocto has the concept of "sstate" (shared state),
> which allows different developers/buildbots/etc. to share build
> artifacts, based on a hash of all the metadata that went into building
> that artifact - and that metadata includes all dependencies (e.g. the
> compiler used etc.). That normally works quite well; usually a clean
> build (without using any sstate cache) done by one developer ends up
> being binary identical to a build done on another host. However, one
> thing that can cause two developers to end up with different builds
> [and thus make one's vmlinux package incompatible with the other's
> kernel-dev package], which is not captured by the metadata hashing, is
> this `git describe`: The output of that can be affected by
>
> (1) git version: before 2.11 git defaulted to a minimum of 7, since
> 2.11 (git.git commit e6c587) the default is dynamic based on the
> number of objects in the repo
> (2) hence even if both run the same git version, the output can differ
> based on how many remotes are being tracked (or just lots of local
> development branches or plain old garbage)
> (3) and of course somebody could have a core.abbrev config setting in
> ~/.gitconfig
>
> So in order to avoid `uname -a` output relying on such random details
> of the build environment which are rather hard to ensure are
> consistent between developers and buildbots, make sure the abbreviated
> sha1 always consists of exactly 12 hex characters. That is consistent
> with the current rule for -stable patches, and is almost always enough
> to identify the head commit unambigously - in the few cases where it
> does not, the v5.4.3-00021- prefix would certainly nail it down.
>
> Signed-off-by: Rasmus Villemoes 
> ---
> v2: use 12 instead of 15, and ensure that the result does have exactly
> 12 hex chars.
>
>  scripts/setlocalversion | 21 -
>  1 file changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> index 20f2efd57b11..bb709eda96cd 100755
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -45,7 +45,7 @@ scm_version()
>
>   # Check for git and a git repo.
>   if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
> -head=$(git rev-parse --verify --short HEAD 2>/dev/null); then
> +head=$(git rev-parse --verify HEAD 2>/dev/null); then
>
>   # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore
>   # it, because this version is defined in the top level Makefile.
> @@ -59,11 +59,22 @@ scm_version()
>   fi
>   # If we are past a tagged commit (like
>   # "v2.6.30-rc5-302-g72357d5"), we pretty print it.
> - if atag="$(git describe 2>/dev/null)"; then
> - echo "$atag" | awk -F- '{printf("-%05d-%s", 
> $(NF-1),$(NF))}'
> -
> - # If we don't have a tag at all we print -g{commitish}.
> + #
> + # Ensure the abbreviated sha1 has exactly 12
> + # hex characters, to make the output
> + # independent of git version, local
> + # core.abbrev settings and/or total number of
> + # objects in the current repository - passing
> + # --abbrev=12 ensures a minimum of 12, and the
> + # awk substr() then picks the 'g' and first 12
> + # hex chars.
> + if atag="$(git describe --abbrev=12 2>/dev/null)"; then
> + echo "$atag" | awk -F- '{printf("-%05d-%s", 
> $(NF-1),substr($(NF),0,13))}'
> +
> + # If we don't have a tag at all we print -g{commitish},
> + # again using exactly 12 hex chars.
>   else
> + head="$(echo $head | cut -c1-12)"
>   

4.9.0+4.19.0: Bug in megasas driver (?), if booting from USB stick

[Nico Schottelius]

Hello kernel hackers,

I've this "funny" problem: if I netboot servers via the firmware in the
network card, the system comes up normal.

If I boot iPXE from a usb stick and then netboot, the megasas driver
fails to init (call trace below, full dmesg attached). The system also
hangs during the init for probably 30 seconds.

Same kernel, same kernel parameters, same OS.

I can reproduce this on Dell R815, Dell R710 with 3.5" disks, but not on
Dell R710 with 2.5" disk slots.

I can also reproduce this with 4.9.0-11-amd64 and 4.19.0-9-amd64
(current Debian Buster).

Does anyone have an idea what the influence booting from an USB stick
can have on the megasas controller? In these boxes there is a Perc H700
and I've seen the same behaviour with Perc H800 as well.

I played with edd=off (which is required for some R710s), but that does
not fix the problem.

Any pointers are much appreciated.

Best regards,

Nico



dmesg-r815
Description: Binary data


[  264.944087] megaraid_sas :05:00.0: Failed to init firmware
[  264.946621] [ cut here ]
[  264.946677] WARNING: CPU: 0 PID: 827 at 
/build/linux-XzZAcJ/linux-4.9.189/kernel/irq/manage.c:1493 __free_irq+0xa2/0x280
[  264.946776] Trying to free already-free IRQ 180
[  264.946821] Modules linked in: sd_mod joydev uas usb_storage hid_generic 
usbhid hid sg sr_mod cdrom ipmi_devintf evdev dcdbas amd64_edac_mod 
edac_mce_amd edac_core ahci libahci kvm_amd kvm irqbypass crct10dif_pclmul 
crc32_pclmul crc32c_intel ohci_pci megaraid_sas(+) ixgbe ghash_clmulni_intel 
ptp libata pps_core mdio mgag200 ohci_hcd aesni_intel aes_x86_64 ttm lrw 
drm_kms_helper ehci_pci gf128mul dca glue_helper bnx2 sp5100_tco ablk_helper 
psmouse ehci_hcd pcspkr serio_raw drm cryptd fam15h_power i2c_algo_bit k10temp 
i2c_piix4 usbcore ipmi_si scsi_mod usb_common shpchp ipmi_msghandler 
acpi_power_meter button
[  264.947638] CPU: 0 PID: 827 Comm: kworker/0:2 Not tainted 4.9.0-11-amd64 #1 
Debian 4.9.189-3
[  264.947716] Hardware name: Dell Inc. PowerEdge R815/04Y8PT, BIOS 3.2.2 
09/15/2014
[  264.947791] Workqueue: events work_for_cpu_fn
[  264.947839]   8ef353d4 a83e7353bc30 

[  264.947927]  8ec7a83b 00b4 a83e7353bc88 
9d3bd2731200
[  264.948013]  00b4 9d3bd27312d4 0246 
8ec7a8bf
[  264.948099] Call Trace:
[  264.948136]  [] ? dump_stack+0x5c/0x78
[  264.948190]  [] ? __warn+0xcb/0xf0
[  264.948242]  [] ? warn_slowpath_fmt+0x5f/0x80
[  264.948313]  [] ? megasas_free_cmds+0x48/0x70 
[megaraid_sas]
[  264.948384]  [] ? __free_irq+0xa2/0x280
[  264.948438]  [] ? free_irq+0x37/0x90
[  264.948498]  [] ? megasas_destroy_irqs+0x45/0x80 
[megaraid_sas]
[  264.948578]  [] ? megasas_probe_one+0xa05/0x1d30 
[megaraid_sas]
[  264.948652]  [] ? __kthread_create_on_node+0x132/0x180
[  264.948721]  [] ? check_preempt_wakeup+0x103/0x210
[  264.948785]  [] ? local_pci_probe+0x44/0xa0
[  264.948842]  [] ? work_for_cpu_fn+0x16/0x20
[  264.948899]  [] ? process_one_work+0x18a/0x430
[  264.948958]  [] ? worker_thread+0x1ca/0x490
[  264.949016]  [] ? process_one_work+0x430/0x430
[  264.949078]  [] ? kthread+0xd9/0xf0
[  264.949130]  [] ? kthread_park+0x60/0x60
[  264.949188]  [] ? ret_from_fork+0x44/0x70
[  264.949243] ---[ end trace 277700523668533a ]---


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch

Kernel panic on new Dell XPS 7390 (5.3)

[Nico Schottelius]

Good morning,

I have just started fighing with the new Dell XPS 7390 and get various
boot errors [0], including a kernel panic with kernel 5.3 as shipped by
Ubuntu 19.10.

I was wondering if anyone has an advice on how to debug this best?

Best,

Nico

[0] https://twitter.com/NicoSchottelius/status/1177540293454979072
[1] https://twitter.com/NicoSchottelius/status/1177545177193254914

--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.

Re: How to turn off IPv4 without disabling IPv6

[Nico Schottelius]

Hey Adam,

thanks for the fast response.


Adam Borowski  writes:

> On Thu, Apr 25, 2019 at 11:32:38AM +0200, Nico Schottelius wrote:
>> running some IPv6 only
>> networks. The systems in the IPv6 only networks do not need any IPv4
>> support anymore and thus for switches/routers we turned the support off.
>
>> Today we tried to turn off IPv4 in the Linux kernel at compile time.
>> But it seems that as soon as we turn off CONFIG_INET, CONFIG_IPV6 is
>> automatically turned off as well.
>
> Even if you don't want global nor even link-scope IPv4, way too many
> programs assume that at least 127.0.0.1 (ie, lo) is working.  They can't be
> reconfigured to use ::1 without patching and rebuilding.

I think we have to distinguish here between 2 kinds of programs:

- stuff that listen()s
- stuff that connect()s

Afaics, the latter does not need any lo connectivity, neither v4 nor
v6. It will use whatever IP address the kernel chooses for outgoing
connections.

For the former, I agree that there might be software that actually
fails without having 127.0.0.1. However, if they bind to 0.0.0.0, the
software will actually not work in IPv6 only network anyway.

The big problem here is:

if I cannot turn off IPv4, I cannot test what needs to be fixed.

> [...]
> That's an extra moving part where there was none before.  Complexity is bad.
> Having the IPv4 stack built just for the lo interface simplifies
> things.

I tend to disagree with this statement: turning off IPv4 first off all
reduces complexity. You can even fully get rid of ARP. Yes, there will
be the need for some changes / updates, but all of this can only be
spotted once IPv4 is turned off.

Best,

Nico

--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.

How to turn off IPv4 without disabling IPv6

[Nico Schottelius]

Good morning kernel hackers,

we are a small company in Switzerland running some IPv6 only
networks. The systems in the IPv6 only networks do not need any IPv4
support anymore and thus for switches/routers we turned the support off.

Today we tried to turn off IPv4 in the Linux kernel at compile time.
But it seems that as soon as we turn off CONFIG_INET, CONFIG_IPV6 is
automatically turned off as well.

While you can argue that "turning off IPv4 is not necessary", this is
not our point. As IPv4 resources have depleted almost everywhere in the
world a move to IPv6 is inevitable, especially if you are a small
organisation offering Internet services.

Being a (new) small organisation you are already disadvantaged in terms of
IPv4 resources that you can afford, so our objective is to make the life
in the IPv6 world as easy as possible.

If we can build operating systems that don't run IPv4 anymore,
operators have at least a certain degree of complexity less and can
start fresh into adventures, without having to care about iptables,
about IPv4 routing, etc.

Coming back to my original question: is there a way or how would we turn
off IPv4 support in the Linux kernel? So far the only operating system
that is reported to be able to run without IPv4 is FreeBSD [0], but I
hope we can add more in the near future.

Best,

Nico

[0] https://ungleich.ch/en-us/cms/blog/2019/01/09/die-ipv4-die/

--
Your Swiss, Open Source and IPv6 Virtual Machine. Now on www.datacenterlight.ch.

Re: Modern Suspend on Dell Latitude 5285 does not resume

[Nico Schottelius]

Good evening Mario,

> Currently the patch does not look at anything in the system to default to S2I 
> vs S3.
> This will affect systems that offer S3 and S2I (even if S3 is broken).
>
> Have you configured /sys/power/mem_sleep to s2idle?
> https://github.com/torvalds/linux/blob/master/Documentation/power/states.txt#L35

indeed, after configuring it to s2idle, it works like charm!

Do you have any plans on defaulting to s2idle for machines that do not
properly support s3?

Best,

Nico


--
Modern, affordable, Swiss Virtual Machines can be found on 
www.datacenterlight.ch

Re: Modern Suspend on Dell Latitude 5285 does not resume

[Nico Schottelius]

Good evening Mario,

> Currently the patch does not look at anything in the system to default to S2I 
> vs S3.
> This will affect systems that offer S3 and S2I (even if S3 is broken).
>
> Have you configured /sys/power/mem_sleep to s2idle?
> https://github.com/torvalds/linux/blob/master/Documentation/power/states.txt#L35

indeed, after configuring it to s2idle, it works like charm!

Do you have any plans on defaulting to s2idle for machines that do not
properly support s3?

Best,

Nico


--
Modern, affordable, Swiss Virtual Machines can be found on 
www.datacenterlight.ch

Modern Suspend on Dell Latitude 5285 does not resume

[Nico Schottelius]

Hello,

following up the recent patch [0] to enable modern suspend on Dell notebooks, I
can report that this patch does *not* fix the situation on Dell Latitude
5285. I have tested with v4.12-10845-g74cbd96 and when closing the "lid"
or triggering sleep by echo mem > /sys/power/state, the system suspends,
but never wakes up again. Trying to resume with the power button does
not have any affect, as it is the case with 4.12.1.

A long power button press to forcefully shutdown the system is
necessary, at which point the notebook responds with blinking
the power LED (3x red, 5x white), which seems not to be defined in
the user manual.

Is there anything I can do to test what is going on?

Best,

Nico

p.s.: The device does also not have any backlight control available in
xorg, even though sysfs exposes a brightness setting - where is the best
place to report this? xorg bugzilla or kernel?

[0] https://lkml.org/lkml/2017/6/23/447

--
Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus

Modern Suspend on Dell Latitude 5285 does not resume

[Nico Schottelius]

Hello,

following up the recent patch [0] to enable modern suspend on Dell notebooks, I
can report that this patch does *not* fix the situation on Dell Latitude
5285. I have tested with v4.12-10845-g74cbd96 and when closing the "lid"
or triggering sleep by echo mem > /sys/power/state, the system suspends,
but never wakes up again. Trying to resume with the power button does
not have any affect, as it is the case with 4.12.1.

A long power button press to forcefully shutdown the system is
necessary, at which point the notebook responds with blinking
the power LED (3x red, 5x white), which seems not to be defined in
the user manual.

Is there anything I can do to test what is going on?

Best,

Nico

p.s.: The device does also not have any backlight control available in
xorg, even though sysfs exposes a brightness setting - where is the best
place to report this? xorg bugzilla or kernel?

[0] https://lkml.org/lkml/2017/6/23/447

--
Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus

Re: [PATCH] setlocalversion: fix error detectition of kernel git repository

[Nico Schottelius]

Hello Xufeng,

why do you think redirecting *all* output to /dev/null is the right
thing todo?

And which problem does it exactly fix?

Do you see that there is a difference between a "return value"
(i.e. exit code) and the output (in this case stdout) of a program?

Best,

Nico

xufeng  writes:

> This patch fixed the error using 'git rev-parse --show-cdup' to check
> that git is used as SCM to track the current directory. The return
> value of this command is not null string when the .git directory is
> not in kernel topdir.
>
> Signed-off-by: Xufeng Wang 
> ---
> scripts/setlocalversion | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> index 966dd39..7966e39 100755
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -43,7 +43,7 @@ scm_version()
> fi
>
> # Check for git and a git repo.
> -if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
> +if test -z "$(git rev-parse --show-cdup &>/dev/null)" &&
> head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
>
> # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore


--
Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus

Re: [PATCH] setlocalversion: fix error detectition of kernel git repository

[Nico Schottelius]

Hello Xufeng,

why do you think redirecting *all* output to /dev/null is the right
thing todo?

And which problem does it exactly fix?

Do you see that there is a difference between a "return value"
(i.e. exit code) and the output (in this case stdout) of a program?

Best,

Nico

xufeng  writes:

> This patch fixed the error using 'git rev-parse --show-cdup' to check
> that git is used as SCM to track the current directory. The return
> value of this command is not null string when the .git directory is
> not in kernel topdir.
>
> Signed-off-by: Xufeng Wang 
> ---
> scripts/setlocalversion | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> index 966dd39..7966e39 100755
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -43,7 +43,7 @@ scm_version()
> fi
>
> # Check for git and a git repo.
> -if test -z "$(git rev-parse --show-cdup 2>/dev/null)" &&
> +if test -z "$(git rev-parse --show-cdup &>/dev/null)" &&
> head=`git rev-parse --verify --short HEAD 2>/dev/null`; then
>
> # If we are at a tagged commit (like "v2.6.30-rc6"), we ignore


--
Werde Teil des modernen Arbeitens im Glarnerland auf www.digitalglarus.ch!
Lese Neuigkeiten auf Twitter: www.twitter.com/DigitalGlarus
Diskutiere mit auf Facebook:  www.facebook.com/digitalglarus

Re: Linux 3.16: O2 Micro MMC missing in lspci

[Nico Schottelius]

Hey Stefan,

(un-)fortunately I don't have the device anymore,
so I cannot test anymore.

Cheers,

Nico

Stefan Richter [Sun, Sep 14, 2014 at 10:24:08AM +0200]:
> On Aug 14 Nico Schottelius wrote:
> > Hello,
> > 
> > when booting into 3.16.0-2-ARCH I miss the following
> > entry in lspci:
> > 
> > [12:50] gold:debug-sd-card-reader% diff 3.15/lspci 3.16/lspci 
> > 17d16
> > < 03:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader
> > Controller (rev 01)
> > 
> > This causes my system to be unable to mount/see the sd cards.
> > My hardware is a Dell E7440 notebook.
> > 
> > I attached dmesg & lspci of both kernels.
> > 
> > Anyone an idea on what might be wrong?
> > 
> > The only related issues I found is
> > https://bugs.archlinux.org/task/26971
> > 
> > and that there was a change in the mmc area:
> > 
> > https://lkml.org/lkml/2014/6/10/491
> > 
> > Cheers,
> > 
> > Nico
> > 
> > p.s.: Please cc on reply
> 
> Both the archlinux bug and the pull request very much appear to be
> unrelated to your issue.  In your case, the MMC subsystem is not involved
> since the PCI device of the SD controller is not exposed to the MMC
> subsystem anymore, just like it is not exposed in lspci anymore.
> 
> I suggest as next steps:
>   - Test whether the issue still exists in the newest kernel that you are
> able to install.  (v3.17-rc4 is current, v3.16.2 is the lastest on in
> the 3.16 branch.)
>   - Post the dmesg output from a successful boot with 3.15 and from an
> unsuccessful boot with 3.16.
> 
> [added Cc: linux-pci]
> -- 
> Stefan Richter
> -=-- =--= -===-
> http://arcgraph.de/sr/

-- 
New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux 3.16: O2 Micro MMC missing in lspci

[Nico Schottelius]

Hey Stefan,

(un-)fortunately I don't have the device anymore,
so I cannot test anymore.

Cheers,

Nico

Stefan Richter [Sun, Sep 14, 2014 at 10:24:08AM +0200]:
 On Aug 14 Nico Schottelius wrote:
  Hello,
  
  when booting into 3.16.0-2-ARCH I miss the following
  entry in lspci:
  
  [12:50] gold:debug-sd-card-reader% diff 3.15/lspci 3.16/lspci 
  17d16
   03:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader
  Controller (rev 01)
  
  This causes my system to be unable to mount/see the sd cards.
  My hardware is a Dell E7440 notebook.
  
  I attached dmesg  lspci of both kernels.
  
  Anyone an idea on what might be wrong?
  
  The only related issues I found is
  https://bugs.archlinux.org/task/26971
  
  and that there was a change in the mmc area:
  
  https://lkml.org/lkml/2014/6/10/491
  
  Cheers,
  
  Nico
  
  p.s.: Please cc on reply
 
 Both the archlinux bug and the pull request very much appear to be
 unrelated to your issue.  In your case, the MMC subsystem is not involved
 since the PCI device of the SD controller is not exposed to the MMC
 subsystem anymore, just like it is not exposed in lspci anymore.
 
 I suggest as next steps:
   - Test whether the issue still exists in the newest kernel that you are
 able to install.  (v3.17-rc4 is current, v3.16.2 is the lastest on in
 the 3.16 branch.)
   - Post the dmesg output from a successful boot with 3.15 and from an
 unsuccessful boot with 3.16.
 
 [added Cc: linux-pci]
 -- 
 Stefan Richter
 -=-- =--= -===-
 http://arcgraph.de/sr/

-- 
New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 3.16: O2 Micro MMC missing in lspci

[Nico Schottelius]

Hello,

when booting into 3.16.0-2-ARCH I miss the following
entry in lspci:

[12:50] gold:debug-sd-card-reader% diff 3.15/lspci 3.16/lspci 
17d16
< 03:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader
Controller (rev 01)

This causes my system to be unable to mount/see the sd cards.
My hardware is a Dell E7440 notebook.

I attached dmesg & lspci of both kernels.

Anyone an idea on what might be wrong?

The only related issues I found is
https://bugs.archlinux.org/task/26971

and that there was a change in the mmc area:

https://lkml.org/lkml/2014/6/10/491

Cheers,

Nico

p.s.: Please cc on reply

-- 
New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.15.7-1-ARCH 
(nobody@var-lib-archbuild-extra-x86_64-thomas) (gcc version 4.9.1 (GCC) ) #1 
SMP PREEMPT Mon Jul 28 20:06:17 CEST 2014
[0.00] Command line: initrd=\EFI\archiso\archiso.img 
archisobasedir=arch archisolabel=ARCH_201408
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0004efff] usable
[0.00] BIOS-e820: [mem 0x0004f000-0x0004] reserved
[0.00] BIOS-e820: [mem 0x0005-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcf64bfff] usable
[0.00] BIOS-e820: [mem 0xcf64c000-0xcf652fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcf653000-0xd027afff] usable
[0.00] BIOS-e820: [mem 0xd027b000-0xd0753fff] reserved
[0.00] BIOS-e820: [mem 0xd0754000-0xd7db3fff] usable
[0.00] BIOS-e820: [mem 0xd7db4000-0xd7ff] reserved
[0.00] BIOS-e820: [mem 0xd800-0xd8758fff] usable
[0.00] BIOS-e820: [mem 0xd8759000-0xd87f] reserved
[0.00] BIOS-e820: [mem 0xd880-0xd8fa9fff] usable
[0.00] BIOS-e820: [mem 0xd8faa000-0xd8ff] ACPI data
[0.00] BIOS-e820: [mem 0xd900-0xda71bfff] usable
[0.00] BIOS-e820: [mem 0xda71c000-0xda7f] ACPI NVS
[0.00] BIOS-e820: [mem 0xda80-0xdbd04fff] usable
[0.00] BIOS-e820: [mem 0xdbd05000-0xdbff] reserved
[0.00] BIOS-e820: [mem 0xdd00-0xdf1f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021edf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ACPI 2.0=0xd8feb000  ACPI=0xd8feb000  SMBIOS=0xf 
[0.00] efi: mem00: type=7, attr=0xf, 
range=[0x-0x1000) (0MB)
[0.00] efi: mem01: type=2, attr=0xf, 
range=[0x1000-0x7000) (0MB)
[0.00] efi: mem02: type=7, attr=0xf, 
range=[0x7000-0x0004f000) (0MB)
[0.00] efi: mem03: type=0, attr=0xf, 
range=[0x0004f000-0x0005) (0MB)
[0.00] efi: mem04: type=7, attr=0xf, 
range=[0x0005-0x0009d000) (0MB)
[0.00] efi: mem05: type=4, attr=0xf, 
range=[0x0009d000-0x0009e000) (0MB)
[0.00] efi: mem06: type=0, attr=0xf, 
range=[0x0009e000-0x000a) (0MB)
[0.00] efi: mem07: type=7, attr=0xf, 
range=[0x0010-0x0100) (15MB)
[0.00] efi: mem08: type=2, attr=0xf, 
range=[0x0100-0x01f6) (15MB)
[0.00] efi: mem09: type=7, attr=0xf, 
range=[0x01f6-0x7ec62000) (1997MB)
[0.00] efi: mem10: type=2, attr=0xf, 
range=[0x7ec62000-0x8000) (19MB)
[0.00] efi: mem11: type=7, attr=0xf, 
range=[0x8000-0xcc776000) (1223MB)
[0.00] efi: mem12: type=4, attr=0xf, 
range=[0xcc776000-0xcc876000) (1MB)
[0.00] efi: mem13: type=7, attr=0xf, 
range=[0xcc876000-0xce6ec000) (30MB)
[0.00] efi: mem14: type=1, attr=0xf, 
range=[0xce6ec000-0xcf64c000) (15MB)
[0.00] efi: mem15: type=10, attr=0xf, 
range=[0xcf64c000-0xcf653000) (0MB)
[0.00] efi: mem16: type=4, 

Linux 3.16: O2 Micro MMC missing in lspci

[Nico Schottelius]

Hello,

when booting into 3.16.0-2-ARCH I miss the following
entry in lspci:

[12:50] gold:debug-sd-card-reader% diff 3.15/lspci 3.16/lspci 
17d16
 03:00.0 SD Host controller: O2 Micro, Inc. SD/MMC Card Reader
Controller (rev 01)

This causes my system to be unable to mount/see the sd cards.
My hardware is a Dell E7440 notebook.

I attached dmesg  lspci of both kernels.

Anyone an idea on what might be wrong?

The only related issues I found is
https://bugs.archlinux.org/task/26971

and that there was a change in the mmc area:

https://lkml.org/lkml/2014/6/10/491

Cheers,

Nico

p.s.: Please cc on reply

-- 
New PGP key: 659B 0D91 E86E 7E24 FD15  69D0 C729 21A1 293F 2D24
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 3.15.7-1-ARCH 
(nobody@var-lib-archbuild-extra-x86_64-thomas) (gcc version 4.9.1 (GCC) ) #1 
SMP PREEMPT Mon Jul 28 20:06:17 CEST 2014
[0.00] Command line: initrd=\EFI\archiso\archiso.img 
archisobasedir=arch archisolabel=ARCH_201408
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0004efff] usable
[0.00] BIOS-e820: [mem 0x0004f000-0x0004] reserved
[0.00] BIOS-e820: [mem 0x0005-0x0009dfff] usable
[0.00] BIOS-e820: [mem 0x0009e000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcf64bfff] usable
[0.00] BIOS-e820: [mem 0xcf64c000-0xcf652fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcf653000-0xd027afff] usable
[0.00] BIOS-e820: [mem 0xd027b000-0xd0753fff] reserved
[0.00] BIOS-e820: [mem 0xd0754000-0xd7db3fff] usable
[0.00] BIOS-e820: [mem 0xd7db4000-0xd7ff] reserved
[0.00] BIOS-e820: [mem 0xd800-0xd8758fff] usable
[0.00] BIOS-e820: [mem 0xd8759000-0xd87f] reserved
[0.00] BIOS-e820: [mem 0xd880-0xd8fa9fff] usable
[0.00] BIOS-e820: [mem 0xd8faa000-0xd8ff] ACPI data
[0.00] BIOS-e820: [mem 0xd900-0xda71bfff] usable
[0.00] BIOS-e820: [mem 0xda71c000-0xda7f] ACPI NVS
[0.00] BIOS-e820: [mem 0xda80-0xdbd04fff] usable
[0.00] BIOS-e820: [mem 0xdbd05000-0xdbff] reserved
[0.00] BIOS-e820: [mem 0xdd00-0xdf1f] reserved
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021edf] usable
[0.00] NX (Execute Disable) protection: active
[0.00] efi: EFI v2.31 by American Megatrends
[0.00] efi:  ACPI 2.0=0xd8feb000  ACPI=0xd8feb000  SMBIOS=0xf 
[0.00] efi: mem00: type=7, attr=0xf, 
range=[0x-0x1000) (0MB)
[0.00] efi: mem01: type=2, attr=0xf, 
range=[0x1000-0x7000) (0MB)
[0.00] efi: mem02: type=7, attr=0xf, 
range=[0x7000-0x0004f000) (0MB)
[0.00] efi: mem03: type=0, attr=0xf, 
range=[0x0004f000-0x0005) (0MB)
[0.00] efi: mem04: type=7, attr=0xf, 
range=[0x0005-0x0009d000) (0MB)
[0.00] efi: mem05: type=4, attr=0xf, 
range=[0x0009d000-0x0009e000) (0MB)
[0.00] efi: mem06: type=0, attr=0xf, 
range=[0x0009e000-0x000a) (0MB)
[0.00] efi: mem07: type=7, attr=0xf, 
range=[0x0010-0x0100) (15MB)
[0.00] efi: mem08: type=2, attr=0xf, 
range=[0x0100-0x01f6) (15MB)
[0.00] efi: mem09: type=7, attr=0xf, 
range=[0x01f6-0x7ec62000) (1997MB)
[0.00] efi: mem10: type=2, attr=0xf, 
range=[0x7ec62000-0x8000) (19MB)
[0.00] efi: mem11: type=7, attr=0xf, 
range=[0x8000-0xcc776000) (1223MB)
[0.00] efi: mem12: type=4, attr=0xf, 
range=[0xcc776000-0xcc876000) (1MB)
[0.00] efi: mem13: type=7, attr=0xf, 
range=[0xcc876000-0xce6ec000) (30MB)
[0.00] efi: mem14: type=1, attr=0xf, 
range=[0xce6ec000-0xcf64c000) (15MB)
[0.00] efi: mem15: type=10, attr=0xf, 
range=[0xcf64c000-0xcf653000) (0MB)
[0.00] efi: mem16: type=4, 

Support for automatic screen rotation on Lenovo Yogo 2 Pro

[Nico Schottelius]

Good morning hackers,

The screen on the Lenovo Yoga 2 Pro can rotate up to 180 degrees and it would 
be awesome
if we could rotate it automatically under Linux. xrandr can already rotate it, 
what is missing 
is an event that we can trigger on. 

Is there any way to find out 
a) if the screen is opened for more than 90 degrees?
a) what the opening angle of the screen is?

I guess there must be support somewhere, as it is supposed to happen
automatically under windows. [1]

I am still facing the problem that there are no keycodes present for
some keys [0] - if you have a hint for this problem, I am wondering 
if anyone has a pointer on how to solve one of these issues?

Cheers,

Nico

[0] https://lkml.org/lkml/2014/1/28/251
[1] I have never tried windows on this device, but from the forums and
marketing I assume it works trigger based on the opening angle.



-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Support for automatic screen rotation on Lenovo Yogo 2 Pro

[Nico Schottelius]

Good morning hackers,

The screen on the Lenovo Yoga 2 Pro can rotate up to 180 degrees and it would 
be awesome
if we could rotate it automatically under Linux. xrandr can already rotate it, 
what is missing 
is an event that we can trigger on. 

Is there any way to find out 
a) if the screen is opened for more than 90 degrees?
a) what the opening angle of the screen is?

I guess there must be support somewhere, as it is supposed to happen
automatically under windows. [1]

I am still facing the problem that there are no keycodes present for
some keys [0] - if you have a hint for this problem, I am wondering 
if anyone has a pointer on how to solve one of these issues?

Cheers,

Nico

[0] https://lkml.org/lkml/2014/1/28/251
[1] I have never tried windows on this device, but from the forums and
marketing I assume it works trigger based on the opening angle.



-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Keycodes missing / wrong on Lenovo Yoga 2 Pro

[Nico Schottelius]

Good day kernel hackers,

when trying out which events are recognised by xev
to adjust my xbindkeysrc, I noticed that various keys
are incorrectly recognised on this machine:

- mute button on the side returns "f", should be xf86audiomute

- fn + f4 returns f4, should be "Lock" (if we have such a symbol)
- fn + f5 returns f5, should be ? (has to arrows on it)
- fn + f6 returns nothing, should be "toggletouchpad" (or whatever
  the name of it is)
  dmesg returns
  [93762.432649] atkbd serio0: Unknown key released (translated set
  2, code 0xbf on isa0060/serio0).
  [93762.432653] atkbd serio0: Use 'setkeycodes e03f ' to
  make it known.

- fn + f8 returns tab, should be ?
- fn + f10 returns Super_L and q, should be "Switchmonitor" 
- fn + home returns pause (correct)
- fn + end returns pause (is there a key for break?)

I am wondering how to fix those keys (xorg, kernel?).
I used 3.12.7 and X 1.15.0 for testing.

Other interesting keys:

- fn + f9 turns of the screen (seems to be hardware wise)

Furthermore I am wondering if there is a sensible way to change
the event I get from the Windows Logo below the touchscreen (currently
reported as Super_L). It would be awesome to be able to able to
distinguish the key between the touchscreen and the windows key.
Also, the "key" below the touchscreen cannot be pressed and combined
with keys on the keyboard.

I have uploaded pictures of the keyboard at
http://home.schottelius.org/~nico/lenovo_yoga_2_pro/

Cheers,

Nico

p.s.: Please cc me on reply.
pps: The kernel fonts are (almost) unreadable when booting this
 device - the 3200x1800 resolution is definitely requiring 
 another font.

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Keycodes missing / wrong on Lenovo Yoga 2 Pro

[Nico Schottelius]

Good day kernel hackers,

when trying out which events are recognised by xev
to adjust my xbindkeysrc, I noticed that various keys
are incorrectly recognised on this machine:

- mute button on the side returns f, should be xf86audiomute

- fn + f4 returns f4, should be Lock (if we have such a symbol)
- fn + f5 returns f5, should be ? (has to arrows on it)
- fn + f6 returns nothing, should be toggletouchpad (or whatever
  the name of it is)
  dmesg returns
  [93762.432649] atkbd serio0: Unknown key released (translated set
  2, code 0xbf on isa0060/serio0).
  [93762.432653] atkbd serio0: Use 'setkeycodes e03f keycode' to
  make it known.

- fn + f8 returns tab, should be ?
- fn + f10 returns Super_L and q, should be Switchmonitor 
- fn + home returns pause (correct)
- fn + end returns pause (is there a key for break?)

I am wondering how to fix those keys (xorg, kernel?).
I used 3.12.7 and X 1.15.0 for testing.

Other interesting keys:

- fn + f9 turns of the screen (seems to be hardware wise)

Furthermore I am wondering if there is a sensible way to change
the event I get from the Windows Logo below the touchscreen (currently
reported as Super_L). It would be awesome to be able to able to
distinguish the key between the touchscreen and the windows key.
Also, the key below the touchscreen cannot be pressed and combined
with keys on the keyboard.

I have uploaded pictures of the keyboard at
http://home.schottelius.org/~nico/lenovo_yoga_2_pro/

Cheers,

Nico

p.s.: Please cc me on reply.
pps: The kernel fonts are (almost) unreadable when booting this
 device - the 3200x1800 resolution is definitely requiring 
 another font.

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] scripts/setlocalversion on write-protected source tree

[Nico Schottelius]

Hey Christian,

Christian Kujau [Sun, Jun 09, 2013 at 05:50:49PM -0700]:
> Hi,
> 
> [errors when using git update-index - different scenarios]
> [...]
> 
> On a side note, I don't think a kernel compilation should alter the source 
> tree (or the .git directory) in any way and I don't see how removing 
> "git update-index" could do any harm. The Mercurial and SVN routines in 
> scripts/setlocalversion don't have any tree-modifying commands, AFAICS. 
> So, maybe the attached patch would be acceptable.
> 
> [...]

As --refresh is being used, I guess (!) the motivation was to update the
index for stat changes that may have taken place elsewhere (like on
NFS) - not sure whether this actually matches (can somebody confirm /
overturn this theory?).

I do however agree with you that setlocalversion should probably not
try to fix this problem, but leave it to the user to update the index,
if necessary.

So I'd personally go for your second patch.

Cheers,

Nico

> diff --git a/scripts/setlocalversion b/scripts/setlocalversion
> index 84b88f1..d105a44 100755
> --- a/scripts/setlocalversion
> +++ b/scripts/setlocalversion
> @@ -71,9 +71,6 @@ scm_version()
>   printf -- '-svn%s' "`git svn find-rev $head`"
>   fi
>  
> - # Update index only on r/w media
> - [ -w . ] && git update-index --refresh --unmerged > /dev/null
> -
>   # Check for uncommitted changes
>   if git diff-index --name-only HEAD | grep -qv 
> "^scripts/package"; then
>   printf '%s' -dirty


-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] scripts/setlocalversion on write-protected source tree

[Nico Schottelius]

Hey Christian,

Christian Kujau [Sun, Jun 09, 2013 at 05:50:49PM -0700]:
 Hi,
 
 [errors when using git update-index - different scenarios]
 [...]
 
 On a side note, I don't think a kernel compilation should alter the source 
 tree (or the .git directory) in any way and I don't see how removing 
 git update-index could do any harm. The Mercurial and SVN routines in 
 scripts/setlocalversion don't have any tree-modifying commands, AFAICS. 
 So, maybe the attached patch would be acceptable.
 
 [...]

As --refresh is being used, I guess (!) the motivation was to update the
index for stat changes that may have taken place elsewhere (like on
NFS) - not sure whether this actually matches (can somebody confirm /
overturn this theory?).

I do however agree with you that setlocalversion should probably not
try to fix this problem, but leave it to the user to update the index,
if necessary.

So I'd personally go for your second patch.

Cheers,

Nico

 diff --git a/scripts/setlocalversion b/scripts/setlocalversion
 index 84b88f1..d105a44 100755
 --- a/scripts/setlocalversion
 +++ b/scripts/setlocalversion
 @@ -71,9 +71,6 @@ scm_version()
   printf -- '-svn%s' `git svn find-rev $head`
   fi
  
 - # Update index only on r/w media
 - [ -w . ]  git update-index --refresh --unmerged  /dev/null
 -
   # Check for uncommitted changes
   if git diff-index --name-only HEAD | grep -qv 
 ^scripts/package; then
   printf '%s' -dirty


-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Jfs-discussion] Out of memory on 3.5 kernels

[Nico Schottelius]

Hey Dave,

Dave Kleikamp [Tue, Nov 27, 2012 at 09:56:58AM -0600]:
> [...] 
> I believe this commit will fix the problem:
> http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4eff96d
> 
> It is targeted for the stable kernels.

Thanks, I'll give it a try, I've v3.7-rc7-25-g2844a48 compiled already
and give the system a reboot this evening.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Jfs-discussion] Out of memory on 3.5 kernels

[Nico Schottelius]

Hey Dave,

Dave Kleikamp [Tue, Nov 27, 2012 at 09:56:58AM -0600]:
 [...] 
 I believe this commit will fix the problem:
 http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4eff96d
 
 It is targeted for the stable kernels.

Thanks, I'll give it a try, I've v3.7-rc7-25-g2844a48 compiled already
and give the system a reboot this evening.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Good morning,

update: this problem still exists on 3.6.2-1-ARCH and it got worse:

I reformatted the external disk to use xfs, but as the my
root filesystem is still jfs, it still appears:

 Active / Total Objects (% used): 642732 / 692268 (92.8%)
 Active / Total Slabs (% used)  : 24801 / 24801 (100.0%)
 Active / Total Caches (% used) : 79 / 111 (71.2%)
 Active / Total Size (% used)   : 603522.30K / 622612.05K (96.9%)
 Minimum / Average / Maximum Object : 0.01K / 0.90K / 15.25K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME   
475548 467649  98%1.21K  18722   26599104K jfs_ip
 25670  19143  74%0.05K302   85  1208K shared_policy_node
 24612  16861  68%0.19K   1172   21  4688K dentry
 24426  19524  79%0.17K   1062   23  4248K vm_area_struct
 21636  21180  97%0.11K601   36  2404K sysfs_dir_cache
 12352   9812  79%0.06K193   64   772K kmalloc-64
 11684   9145  78%0.09K254   46  1016K anon_vma
  9855   8734  88%0.58K365   27  5840K inode_cache
  9728   9281  95%0.01K 19  51276K kmalloc-8
  8932   4411  49%0.55K319   28  5104K radix_tree_node
  6336   5760  90%0.25K198   32  1584K kmalloc-256
  5632   5632 100%0.02K 22  25688K kmalloc-16
  4998   2627  52%0.09K119   42   476K kmalloc-96
  4998   3893  77%0.04K 49  102   196K Acpi-Namespace
  4736   3887  82%0.03K 37  128   148K kmalloc-32
  4144   4144 100%0.07K 74   56   296K Acpi-ParseExt
  3740   3740 100%0.02K 22  17088K numa_policy
  3486   3023  86%0.19K166   21   664K kmalloc-192
  3200   2047  63%0.12K100   32   400K kmalloc-128
  2304   2074  90%0.50K 72   32  1152K kmalloc-512
  2136   2019  94%0.64K 89   24  1424K proc_inode_cache
  2080   2080 100%0.12K 65   32   260K jfs_mp
  2024   1890  93%0.70K 88   23  1408K shmem_inode_cache
  1632   1556  95%1.00K 51   32  1632K kmalloc-1024


I am wondering if anyone is feeling responsible for this bug or if the mid-term
solution is to move away from jfs?

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Good morning,

update: this problem still exists on 3.6.2-1-ARCH and it got worse:

I reformatted the external disk to use xfs, but as the my
root filesystem is still jfs, it still appears:

 Active / Total Objects (% used): 642732 / 692268 (92.8%)
 Active / Total Slabs (% used)  : 24801 / 24801 (100.0%)
 Active / Total Caches (% used) : 79 / 111 (71.2%)
 Active / Total Size (% used)   : 603522.30K / 622612.05K (96.9%)
 Minimum / Average / Maximum Object : 0.01K / 0.90K / 15.25K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME   
475548 467649  98%1.21K  18722   26599104K jfs_ip
 25670  19143  74%0.05K302   85  1208K shared_policy_node
 24612  16861  68%0.19K   1172   21  4688K dentry
 24426  19524  79%0.17K   1062   23  4248K vm_area_struct
 21636  21180  97%0.11K601   36  2404K sysfs_dir_cache
 12352   9812  79%0.06K193   64   772K kmalloc-64
 11684   9145  78%0.09K254   46  1016K anon_vma
  9855   8734  88%0.58K365   27  5840K inode_cache
  9728   9281  95%0.01K 19  51276K kmalloc-8
  8932   4411  49%0.55K319   28  5104K radix_tree_node
  6336   5760  90%0.25K198   32  1584K kmalloc-256
  5632   5632 100%0.02K 22  25688K kmalloc-16
  4998   2627  52%0.09K119   42   476K kmalloc-96
  4998   3893  77%0.04K 49  102   196K Acpi-Namespace
  4736   3887  82%0.03K 37  128   148K kmalloc-32
  4144   4144 100%0.07K 74   56   296K Acpi-ParseExt
  3740   3740 100%0.02K 22  17088K numa_policy
  3486   3023  86%0.19K166   21   664K kmalloc-192
  3200   2047  63%0.12K100   32   400K kmalloc-128
  2304   2074  90%0.50K 72   32  1152K kmalloc-512
  2136   2019  94%0.64K 89   24  1424K proc_inode_cache
  2080   2080 100%0.12K 65   32   260K jfs_mp
  2024   1890  93%0.70K 88   23  1408K shmem_inode_cache
  1632   1556  95%1.00K 51   32  1632K kmalloc-1024


I am wondering if anyone is feeling responsible for this bug or if the mid-term
solution is to move away from jfs?

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Very bad performance on Qemu/KVM

[Nico Schottelius]

Good morning LKML,

I see extremely slow virtual machines
running on qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
on Centos 6.3 with Linux 2.6.32-279.5.2.el6.x86_64 on a
64 core machine using AMD Opteron(TM) Processor 6276 (dell r815).

The guests are Centos 6.3, Linux 2.6.32-220.13.1.el6.x86_64.
The disk images reside on local storage, ext4 filesystem.

I checked that kvm is loaded and enabled. I changed
-drive to use if=virtio, -net to use model=virtio.

>From the processes running it seems that cpu performance is the
bottleneck. I added -cpu host to skip the emulation, but this did
not fix the issue.

Comparing the performance to qemu running on a xenserver, performance is
at most half of it.


Does anyone of you have a good pointer how to debug this further or are
there any known issues with the given setup? 

I'm happy for every pointer I get, as there seems to be no easy to spot
issue.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Very bad performance on Qemu/KVM

[Nico Schottelius]

Good morning LKML,

I see extremely slow virtual machines
running on qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
on Centos 6.3 with Linux 2.6.32-279.5.2.el6.x86_64 on a
64 core machine using AMD Opteron(TM) Processor 6276 (dell r815).

The guests are Centos 6.3, Linux 2.6.32-220.13.1.el6.x86_64.
The disk images reside on local storage, ext4 filesystem.

I checked that kvm is loaded and enabled. I changed
-drive to use if=virtio, -net to use model=virtio.

From the processes running it seems that cpu performance is the
bottleneck. I added -cpu host to skip the emulation, but this did
not fix the issue.

Comparing the performance to qemu running on a xenserver, performance is
at most half of it.


Does anyone of you have a good pointer how to debug this further or are
there any known issues with the given setup? 

I'm happy for every pointer I get, as there seems to be no easy to spot
issue.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Hey Valdis,

valdis.kletni...@vt.edu [Fri, Oct 05, 2012 at 11:48:04AM -0400]:
> On Wed, 03 Oct 2012 23:23:11 +0200, Nico Schottelius said:
> 
> > does anyone of you have a clue so far what may be causing the huge
> > slab usage?
> >
> > I've just found an interesting detail: umounting and cryptsetup
> > luksClosing frees up the used memory (not sure which one was freeing
> > up)
> 
> For what it's worth, I'm seeing a similar problem in linux-next on my laptop -
> trying to run a backup to an external hard drive that has a LUKS partition on
> it will OOM. (For some reason having the external LUKS partition is much more
> problematic than the LVM-on-LUKS on the internal drive)

Indeed, I also have the internal drive encrypted with LUKS, also jfs
on it, but the problem only occurs on the external drive.

Is there the possibility that the JFS on the external drive got into a
state that may caus JFS to behave unexpected? If this is true, it would
explain why it happens only with the external drive and also accross
kernel versions.

But "good" to hear I am not the only one affected anymore.

Cheers,

Nico


-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0


pgpO827rYUmiT.pgp
Description: PGP signature

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Hey Valdis,

valdis.kletni...@vt.edu [Fri, Oct 05, 2012 at 11:48:04AM -0400]:
 On Wed, 03 Oct 2012 23:23:11 +0200, Nico Schottelius said:
 
  does anyone of you have a clue so far what may be causing the huge
  slab usage?
 
  I've just found an interesting detail: umounting and cryptsetup
  luksClosing frees up the used memory (not sure which one was freeing
  up)
 
 For what it's worth, I'm seeing a similar problem in linux-next on my laptop -
 trying to run a backup to an external hard drive that has a LUKS partition on
 it will OOM. (For some reason having the external LUKS partition is much more
 problematic than the LVM-on-LUKS on the internal drive)

Indeed, I also have the internal drive encrypted with LUKS, also jfs
on it, but the problem only occurs on the external drive.

Is there the possibility that the JFS on the external drive got into a
state that may caus JFS to behave unexpected? If this is true, it would
explain why it happens only with the external drive and also accross
kernel versions.

But good to hear I am not the only one affected anymore.

Cheers,

Nico


-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0


pgpO827rYUmiT.pgp
Description: PGP signature

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

David Rientjes [Mon, Sep 24, 2012 at 03:43:27PM -0700]:
>  [...]
> 
> And those objects are consuming ~2.3GB of slab on your 4GB machine and 
> seems to only have occurred between v3.4.2 to v3.5.3.
> 
> It would be interesting to see what kmemleak would tell us.

As the Archlinux kernel does not support kmemleak:

[8:04] brief:android-apk% zgrep -i meml /proc/config.gz
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_DEBUG_KMEMLEAK is not set

I'll give the latest kernel tree from Linus a try this evening and if it
is in there. If not, I'll go back to 3.5.4 in Linus tree and try again.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Good morning,

Dave Kleikamp [Tue, Sep 25, 2012 at 10:07:14AM -0500]:
> >>  Active / Total Objects (% used): 1165130 / 1198087 (97.2%)
> >>  Active / Total Slabs (% used)  : 81027 / 81027 (100.0%)
> >>  Active / Total Caches (% used) : 69 / 101 (68.3%)
> >>  Active / Total Size (% used)   : 1237249.81K / 1246521.94K (99.3%)
> >>  Minimum / Average / Maximum Object : 0.01K / 1.04K / 15.23K
> >>
> >>   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
> >>
> >> 993607 993607 100%1.21K  75358   26   2411456K jfs_ip
> > 
> > Well that doesn't look good.  100% of the inode cache for jfs are being 
> > used which either means
> > 
> >  - there's a memory leak, or
> 
> maybe a missing iput() somewhere?
> 
> Nico, does unmounting the usb drive after killing the backup clean up
> the jfs inode cache?

Iirc, it does not. I'll check this evening, because doing the backup
currently forces me to reboot my productive system.

> >  - there's some sort of throttling issue in jfs.
> > 
> > And those objects are consuming ~2.3GB of slab on your 4GB machine and 
> > seems to only have occurred between v3.4.2 to v3.5.3.
> 
> Almost nothing in jfs has changed between these releases. Only this:
> 
> vfs: Rename end_writeback() to clear_inode()

The other obscurity is that the root filesystem is also jfs - it's not
only the usb disk.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

David Rientjes [Mon, Sep 24, 2012 at 03:43:27PM -0700]:
  [...]
 
 And those objects are consuming ~2.3GB of slab on your 4GB machine and 
 seems to only have occurred between v3.4.2 to v3.5.3.
 
 It would be interesting to see what kmemleak would tell us.

As the Archlinux kernel does not support kmemleak:

[8:04] brief:android-apk% zgrep -i meml /proc/config.gz
CONFIG_INPUT_FF_MEMLESS=m
# CONFIG_DEBUG_KMEMLEAK is not set

I'll give the latest kernel tree from Linus a try this evening and if it
is in there. If not, I'll go back to 3.5.4 in Linus tree and try again.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Good morning,

Dave Kleikamp [Tue, Sep 25, 2012 at 10:07:14AM -0500]:
   Active / Total Objects (% used): 1165130 / 1198087 (97.2%)
   Active / Total Slabs (% used)  : 81027 / 81027 (100.0%)
   Active / Total Caches (% used) : 69 / 101 (68.3%)
   Active / Total Size (% used)   : 1237249.81K / 1246521.94K (99.3%)
   Minimum / Average / Maximum Object : 0.01K / 1.04K / 15.23K
 
OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
 
  993607 993607 100%1.21K  75358   26   2411456K jfs_ip
  
  Well that doesn't look good.  100% of the inode cache for jfs are being 
  used which either means
  
   - there's a memory leak, or
 
 maybe a missing iput() somewhere?
 
 Nico, does unmounting the usb drive after killing the backup clean up
 the jfs inode cache?

Iirc, it does not. I'll check this evening, because doing the backup
currently forces me to reboot my productive system.

   - there's some sort of throttling issue in jfs.
  
  And those objects are consuming ~2.3GB of slab on your 4GB machine and 
  seems to only have occurred between v3.4.2 to v3.5.3.
 
 Almost nothing in jfs has changed between these releases. Only this:
 
 vfs: Rename end_writeback() to clear_inode()

The other obscurity is that the root filesystem is also jfs - it's not
only the usb disk.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Hey Arend,

just while running, I got the following brcmsmac related error:

[17336.572558] WARNING: at drivers/net/wireless/brcm80211/brcmsmac/main.c:7968 
brcms_c_wait_for_tx_completion+0x99/0xb0 [brcmsmac]()
[17336.572562] Hardware name: MacBookAir4,2
[17336.572565] Modules linked in: sha256_generic snd_hda_codec_hdmi 
snd_hda_codec_cirrus ext4 jbd2 mbcache arc4 uvcvideo brcmsmac videobuf2_vmalloc 
videobuf2_memops cordic brcmutil btusb bluetooth i915 videobuf2_core mac80211 
videodev crc16 acpi_cpufreq snd_hda_intel media i2c_algo_bit cfg80211 mperf 
drm_kms_helper snd_hda_codec rfkill joydev bcm5974 iTCO_wdt iTCO_vendor_support 
i2c_i801 intel_agp lpc_ich applesmc evdev microcode drm coretemp input_polldev 
pcspkr intel_gtt mfd_core i2c_core processor bcma snd_hwdep video button 
battery apple_bl mei ac snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc 
snd_timer snd soundcore kvm_intel kvm nfs nfs_acl lockd auth_rpcgss sunrpc 
fscache autofs4 jfs xts gf128mul dm_crypt dm_mod sd_mod pata_acpi ata_generic 
hid_generic usb_storage hid_apple usbhid hid uhci_hcd aesni_intel aes_x86_64 
aes_generic ghash_clmulni_intel cryptd crc32c_intel ata_piix libata scsi_mod 
ehci_hcd usbcore usb_common
[17336.572716] Pid: 27714, comm: kworker/u:1 Not tainted 3.5.4-1-ARCH #1
[17336.572719] Call Trace:
[17336.572734]  [] warn_slowpath_common+0x7f/0xc0
[17336.572743]  [] warn_slowpath_null+0x1a/0x20
[17336.572759]  [] brcms_c_wait_for_tx_completion+0x99/0xb0 
[brcmsmac]
[17336.572769]  [] brcms_ops_flush+0x3b/0x60 [brcmsmac]
[17336.572792]  [] ieee80211_mgd_probe_ap_send+0xc9/0x230 
[mac80211]
[17336.572809]  [] ieee80211_mgd_probe_ap.part.22+0x10f/0x130 
[mac80211]
[17336.572823]  [] 
ieee80211_beacon_connection_loss_work+0xad/0x160 [mac80211]
[17336.572833]  [] process_one_work+0x12a/0x440
[17336.572848]  [] ? 
ieee80211_mgd_probe_ap.part.22+0x130/0x130 [mac80211]
[17336.572857]  [] worker_thread+0x12e/0x2d0
[17336.572865]  [] ? manage_workers.isra.26+0x1f0/0x1f0
[17336.572872]  [] kthread+0x93/0xa0
[17336.572880]  [] kernel_thread_helper+0x4/0x10
[17336.572888]  [] ? kthread_freezable_should_stop+0x70/0x70
[17336.572894]  [] ? gs_change+0x13/0x13
[17336.572898] ---[ end trace 87315886d62eca54 ]---


Things are still running, though and slab is ~274 MiB.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Hey Arend,

Arend van Spriel [Thu, Sep 20, 2012 at 09:44:18AM +0200]:
> Hi Nico,
> 
> Being curious (and suspicious) over here. Are you doing the rsync
> over wireless interface using brcmsmac? I am currently looking at
> bugzilla #47721 (see [1]) and maybe this is related.

No, the rsync actually goes to a local usb disk that is encrypted
with luks.

The only issue with brcmsmac currently is that after suspend & resume,
I've to manually do reassociate - it thinks it is associated, but no
packets are being received by the card (using tshark).

> [1] https://bugzilla.kernel.org/show_bug.cgi?id=47721

Uh, this is ugly. I'll have a look at brcmsmac related messages, before
the kernel buffer fills up again.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Hey David,

David Rientjes [Wed, Sep 19, 2012 at 11:54:54PM -0700]:
> On Thu, 20 Sep 2012, Nico Schottelius wrote:
> 
> > for some time the slab usage is quite high (~3.2 GiB) and whenever I try
> > to do a backup with ccollect (which is using rsync), a lot of processes
> > (like chromium) are being killed over night.
> > 
> 
> Yeah, over 81% of your memory is consumed by slab and that doesn't shrink 
> over the duration of the log you posted.  It would be interesting to see 
> if there was a leak somewhere: try looking at slabtop and determining if 
> you have a cache using an egregious amount of memory;

I already had to reboot, because no now process was starting / only
starting extremly slowly.

> if there aren't any 
> clear winners, then we'll still see what is hogging most of your memory 
> and see how it compares to 3.4.2.  You can also check if there is a leak 
> using kmemleak, but this requires a reboot (see 
> Documentation/kmemleak.txt).

I'll have a look at this one after the next reboot; I also have to
update to a recent kernel and enable CONFIG_DEBUG_KMEMLEAK, which is
missing in Archlinux' kernel.

Thanks for the pointers, it can only take a day until I have this
problem again - will then follow up this mail.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Hey David,

David Rientjes [Wed, Sep 19, 2012 at 11:54:54PM -0700]:
 On Thu, 20 Sep 2012, Nico Schottelius wrote:
 
  for some time the slab usage is quite high (~3.2 GiB) and whenever I try
  to do a backup with ccollect (which is using rsync), a lot of processes
  (like chromium) are being killed over night.
  
 
 Yeah, over 81% of your memory is consumed by slab and that doesn't shrink 
 over the duration of the log you posted.  It would be interesting to see 
 if there was a leak somewhere: try looking at slabtop and determining if 
 you have a cache using an egregious amount of memory;

I already had to reboot, because no now process was starting / only
starting extremly slowly.

 if there aren't any 
 clear winners, then we'll still see what is hogging most of your memory 
 and see how it compares to 3.4.2.  You can also check if there is a leak 
 using kmemleak, but this requires a reboot (see 
 Documentation/kmemleak.txt).

I'll have a look at this one after the next reboot; I also have to
update to a recent kernel and enable CONFIG_DEBUG_KMEMLEAK, which is
missing in Archlinux' kernel.

Thanks for the pointers, it can only take a day until I have this
problem again - will then follow up this mail.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Hey Arend,

Arend van Spriel [Thu, Sep 20, 2012 at 09:44:18AM +0200]:
 Hi Nico,
 
 Being curious (and suspicious) over here. Are you doing the rsync
 over wireless interface using brcmsmac? I am currently looking at
 bugzilla #47721 (see [1]) and maybe this is related.

No, the rsync actually goes to a local usb disk that is encrypted
with luks.

The only issue with brcmsmac currently is that after suspend  resume,
I've to manually do reassociate - it thinks it is associated, but no
packets are being received by the card (using tshark).

 [1] https://bugzilla.kernel.org/show_bug.cgi?id=47721

Uh, this is ugly. I'll have a look at brcmsmac related messages, before
the kernel buffer fills up again.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory on 3.5 kernels

[Nico Schottelius]

Hey Arend,

just while running, I got the following brcmsmac related error:

[17336.572558] WARNING: at drivers/net/wireless/brcm80211/brcmsmac/main.c:7968 
brcms_c_wait_for_tx_completion+0x99/0xb0 [brcmsmac]()
[17336.572562] Hardware name: MacBookAir4,2
[17336.572565] Modules linked in: sha256_generic snd_hda_codec_hdmi 
snd_hda_codec_cirrus ext4 jbd2 mbcache arc4 uvcvideo brcmsmac videobuf2_vmalloc 
videobuf2_memops cordic brcmutil btusb bluetooth i915 videobuf2_core mac80211 
videodev crc16 acpi_cpufreq snd_hda_intel media i2c_algo_bit cfg80211 mperf 
drm_kms_helper snd_hda_codec rfkill joydev bcm5974 iTCO_wdt iTCO_vendor_support 
i2c_i801 intel_agp lpc_ich applesmc evdev microcode drm coretemp input_polldev 
pcspkr intel_gtt mfd_core i2c_core processor bcma snd_hwdep video button 
battery apple_bl mei ac snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc 
snd_timer snd soundcore kvm_intel kvm nfs nfs_acl lockd auth_rpcgss sunrpc 
fscache autofs4 jfs xts gf128mul dm_crypt dm_mod sd_mod pata_acpi ata_generic 
hid_generic usb_storage hid_apple usbhid hid uhci_hcd aesni_intel aes_x86_64 
aes_generic ghash_clmulni_intel cryptd crc32c_intel ata_piix libata scsi_mod 
ehci_hcd usbcore usb_common
[17336.572716] Pid: 27714, comm: kworker/u:1 Not tainted 3.5.4-1-ARCH #1
[17336.572719] Call Trace:
[17336.572734]  [81051a3f] warn_slowpath_common+0x7f/0xc0
[17336.572743]  [81051a9a] warn_slowpath_null+0x1a/0x20
[17336.572759]  [a063bd29] brcms_c_wait_for_tx_completion+0x99/0xb0 
[brcmsmac]
[17336.572769]  [a062e1bb] brcms_ops_flush+0x3b/0x60 [brcmsmac]
[17336.572792]  [a04a2f69] ieee80211_mgd_probe_ap_send+0xc9/0x230 
[mac80211]
[17336.572809]  [a04a374f] ieee80211_mgd_probe_ap.part.22+0x10f/0x130 
[mac80211]
[17336.572823]  [a04a381d] 
ieee80211_beacon_connection_loss_work+0xad/0x160 [mac80211]
[17336.572833]  [8106effa] process_one_work+0x12a/0x440
[17336.572848]  [a04a3770] ? 
ieee80211_mgd_probe_ap.part.22+0x130/0x130 [mac80211]
[17336.572857]  [8106f85e] worker_thread+0x12e/0x2d0
[17336.572865]  [8106f730] ? manage_workers.isra.26+0x1f0/0x1f0
[17336.572872]  [81074f73] kthread+0x93/0xa0
[17336.572880]  [81486864] kernel_thread_helper+0x4/0x10
[17336.572888]  [81074ee0] ? kthread_freezable_should_stop+0x70/0x70
[17336.572894]  [81486860] ? gs_change+0x13/0x13
[17336.572898] ---[ end trace 87315886d62eca54 ]---


Things are still running, though and slab is ~274 MiB.

Cheers,

Nico

-- 
PGP key: 7ED9 F7D3 6B10 81D7 0EC5  5C09 D7DC C8E4 3187 7DF0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Out of memory and no killable processes: 2.6.22-2-686-bigmem

[Nico Schottelius]

Hello Robert,

Robert Hancock [Tue, Dec 18, 2007 at 06:43:22PM -0600]:
> How much RAM is in these machines?

8 GiB

> If you're running tons of memory, it 
> really is better to run a 64-bit kernel if possible.

Sure? Afaik that results in a bit slower access to memory and appart
from being able to address MUCH more memory doesn't change the
situation.

Perhaps I missed something.

And updating to 64 Bit kernel also implies changing the userland, so
a reinstall would be necessary, wouldn't it?

> I believe there are 
> some cases where low memory can be pretty easily exhausted on machines with 
> lots of high memory.

Some minutes ago the third machine of that type freezed.
with 7 GiB of *free* memory, before getting oom+panic.

The thing that looks pretty the same is that the inode table / open
inodes shrinked very heavy from 41k to about 2k before the freeze
in about 3 days.

Same kernel, same Dell 1955 hardware, different machine.

Is it possible to debug this issue somehow?

Nico

-- 
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C


signature.asc
Description: Digital signature

Out of memory and no killable processes: 2.6.22-2-686-bigmem

[Nico Schottelius]

Hello!

We are running Debian with 2.6.22-2-686-bigmem on Dell Blade 1955 hardware
and get a Kernel Panic with oom + message that there are no processes
left to kill:

http://home.schottelius.org/~nico/unix/linux/oom_no_killable-2.6.22-1.jpeg

Anyone an idea, what's the cause for that? This error happened on two of
those machines,

What I can see in our analysis done with munin is that the number of
open inodes and inode table size decreased within some days from 40k
to next to zero. Munin uses

   awk '{print "used.value " $1-$2 "\nmax.value " $1}' < /proc/sys/fs/inode-nr

to log those value (happened on both machines).

Thanks for any hint and CC as usual, please.

Nico

-- 
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C


signature.asc
Description: Digital signature

Out of memory and no killable processes: 2.6.22-2-686-bigmem

[Nico Schottelius]

Hello!

We are running Debian with 2.6.22-2-686-bigmem on Dell Blade 1955 hardware
and get a Kernel Panic with oom + message that there are no processes
left to kill:

http://home.schottelius.org/~nico/unix/linux/oom_no_killable-2.6.22-1.jpeg

Anyone an idea, what's the cause for that? This error happened on two of
those machines,

What I can see in our analysis done with munin is that the number of
open inodes and inode table size decreased within some days from 40k
to next to zero. Munin uses

   awk '{print used.value  $1-$2 \nmax.value  $1}'  /proc/sys/fs/inode-nr

to log those value (happened on both machines).

Thanks for any hint and CC as usual, please.

Nico

-- 
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C


signature.asc
Description: Digital signature

Re: Out of memory and no killable processes: 2.6.22-2-686-bigmem

[Nico Schottelius]

Hello Robert,

Robert Hancock [Tue, Dec 18, 2007 at 06:43:22PM -0600]:
 How much RAM is in these machines?

8 GiB

 If you're running tons of memory, it 
 really is better to run a 64-bit kernel if possible.

Sure? Afaik that results in a bit slower access to memory and appart
from being able to address MUCH more memory doesn't change the
situation.

Perhaps I missed something.

And updating to 64 Bit kernel also implies changing the userland, so
a reinstall would be necessary, wouldn't it?

 I believe there are 
 some cases where low memory can be pretty easily exhausted on machines with 
 lots of high memory.

Some minutes ago the third machine of that type freezed.
with 7 GiB of *free* memory, before getting oom+panic.

The thing that looks pretty the same is that the inode table / open
inodes shrinked very heavy from 41k to about 2k before the freeze
in about 3 days.

Same kernel, same Dell 1955 hardware, different machine.

Is it possible to debug this issue somehow?

Nico

-- 
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C


signature.asc
Description: Digital signature

Thanks for /dev/input/* and acpi!

[Nico Schottelius]

Hello everybody!

I'm just playing around with netlink and all the interesting event
devices in 2.6.23.9, because I see that acpid still uses
/proc/acpi/event.

And I must say that the whole event system is pretty fun:
Easy to use, mostly documentated in linux/input.h and
helpful ioctl()s.

I did some hacking on it and if somebody wants to see his / her
acpi events without /proc/acpi/event, she / he can try some of the hacks
under

http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=linux-event-netlink.git;a=summary

Many greetings,

Nico

P.S.: If you reply, CC me, not subscribed.
P.P.S.: If I see how easy it is, I really think of spending some time on
gpm again, to resurrect it and the work on gpm2...

-- 
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C


signature.asc
Description: Digital signature

Thanks for /dev/input/* and acpi!

[Nico Schottelius]

Hello everybody!

I'm just playing around with netlink and all the interesting event
devices in 2.6.23.9, because I see that acpid still uses
/proc/acpi/event.

And I must say that the whole event system is pretty fun:
Easy to use, mostly documentated in linux/input.h and
helpful ioctl()s.

I did some hacking on it and if somebody wants to see his / her
acpi events without /proc/acpi/event, she / he can try some of the hacks
under

http://unix.schottelius.org/cgi-bin/gitweb.cgi?p=linux-event-netlink.git;a=summary

Many greetings,

Nico

P.S.: If you reply, CC me, not subscribed.
P.P.S.: If I see how easy it is, I really think of spending some time on
gpm again, to resurrect it and the work on gpm2...

-- 
Think about Free and Open Source Software (FOSS).
http://nico.schottelius.org/documentations/foss/the-term-foss/

PGP: BFE4 C736 ABE5 406F 8F42  F7CF B8BE F92A 9885 188C


signature.asc
Description: Digital signature

halt: init exits/panic

[Nico Schottelius]

Hello!

What's the 'correct behaviour' of an init system, if someone wants
to shutdown the system?

I currently do:

- call reboot(RB_POWER_OFF/RB_AUTOBOOT/RB_HALT_SYSTEM)
- _exit(0)

Is this exit() call wrong? If I do RB_HALT_SYSTEM and _exit(0) after,
the kernel panics.

Should init simply sleep, return to normal processing or exit?

Sincerly,

Nico

-- 
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org


pgpvAMi3nbMF8.pgp
Description: PGP signature

halt: init exits/panic

[Nico Schottelius]

Hello!

What's the 'correct behaviour' of an init system, if someone wants
to shutdown the system?

I currently do:

- call reboot(RB_POWER_OFF/RB_AUTOBOOT/RB_HALT_SYSTEM)
- _exit(0)

Is this exit() call wrong? If I do RB_HALT_SYSTEM and _exit(0) after,
the kernel panics.

Should init simply sleep, return to normal processing or exit?

Sincerly,

Nico

-- 
Keep it simple  stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org


pgpvAMi3nbMF8.pgp
Description: PGP signature

Re: /proc/cpuinfo format - arch dependent!

[Nico Schottelius]

Lee Revell [Tue, Apr 19, 2005 at 04:42:12PM -0400]:
> On Tue, 2005-04-19 at 22:00 +0200, Nico Schottelius wrote:
> > Can you tell me which ones?
> > 
> 
> Multimedia apps like JACK and mplayer that use the TSC for high res
> timing need to know the CPU speed, and /proc/cpuinfo is the fast way to
> get it.
> 
> Why don't you create sysfs entries instead?  It would be better to have
> all the cpuinfo contents as one value per file anyway (faster
> application startup).

Well, sounds very good. It's a chance for me to learn to program
sysfs and also to create something useful.

So the right location to place that data would be
/sys/devices/system/cpu/cpuX?

Nico

-- 
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org
-
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/cpuinfo format - arch dependent!

[Nico Schottelius]

Lee Revell [Tue, Apr 19, 2005 at 03:17:00PM -0400]:
> On Tue, 2005-04-19 at 09:24 -0400, Lennart Sorensen wrote:
> > On Tue, Apr 19, 2005 at 02:15:30PM +0200, Nico Schottelius wrote:
> > > When I wrote schwanz3(*) for fun, I noticed /proc/cpuinfo
> > > varies very much on different architectures.
> > > 
> > > Is it possible to make it look more identical (as far as the different
> > > archs allow it)?
> > > 
> > > So that one at least can count the cpus on every system the same way.
> > > 
> > > If so, who would the one I should contact and who would accept / verify
> > > a patch doing that?
> > 
> > If you change it now, how many tools would break?
> > 
> 
> Lots.  Please don't change the format of /proc/cpuinfo.

Can you tell me which ones?

And if there are really that many tools, which are dependent on
those information, wouldn't it be much more senseful to make
it (as far as possible) the same?

I must say I was really impressed, how easy I got the number of
cpus on *BSD (I am not a bsd user, still impressed).

They also have the same format on every arch and mostly the same
between different bsds (as far as I have seen).

In general, where are the advantages of having very different cpuinfo
formats? Tools would need to know less about the arch and could
depend on "I am on Linux" only.

Just some thoughts,

Nico

> 
> Lee
> 
> 

-- 
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org
-
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/cpuinfo format - arch dependent!

[Nico Schottelius]

Hello!

When I wrote schwanz3(*) for fun, I noticed /proc/cpuinfo
varies very much on different architectures.

Is it possible to make it look more identical (as far as the different
archs allow it)?

So that one at least can count the cpus on every system the same way.

If so, who would the one I should contact and who would accept / verify
a patch doing that?

Greetings,

Nico

-- 
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org
-
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/cpuinfo format - arch dependent!

[Nico Schottelius]

Hello!

When I wrote schwanz3(*) for fun, I noticed /proc/cpuinfo
varies very much on different architectures.

Is it possible to make it look more identical (as far as the different
archs allow it)?

So that one at least can count the cpus on every system the same way.

If so, who would the one I should contact and who would accept / verify
a patch doing that?

Greetings,

Nico

-- 
Keep it simple  stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org
-
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/cpuinfo format - arch dependent!

[Nico Schottelius]

Lee Revell [Tue, Apr 19, 2005 at 03:17:00PM -0400]:
 On Tue, 2005-04-19 at 09:24 -0400, Lennart Sorensen wrote:
  On Tue, Apr 19, 2005 at 02:15:30PM +0200, Nico Schottelius wrote:
   When I wrote schwanz3(*) for fun, I noticed /proc/cpuinfo
   varies very much on different architectures.
   
   Is it possible to make it look more identical (as far as the different
   archs allow it)?
   
   So that one at least can count the cpus on every system the same way.
   
   If so, who would the one I should contact and who would accept / verify
   a patch doing that?
  
  If you change it now, how many tools would break?
  
 
 Lots.  Please don't change the format of /proc/cpuinfo.

Can you tell me which ones?

And if there are really that many tools, which are dependent on
those information, wouldn't it be much more senseful to make
it (as far as possible) the same?

I must say I was really impressed, how easy I got the number of
cpus on *BSD (I am not a bsd user, still impressed).

They also have the same format on every arch and mostly the same
between different bsds (as far as I have seen).

In general, where are the advantages of having very different cpuinfo
formats? Tools would need to know less about the arch and could
depend on I am on Linux only.

Just some thoughts,

Nico

 
 Lee
 
 

-- 
Keep it simple  stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org
-
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/cpuinfo format - arch dependent!

[Nico Schottelius]

Lee Revell [Tue, Apr 19, 2005 at 04:42:12PM -0400]:
 On Tue, 2005-04-19 at 22:00 +0200, Nico Schottelius wrote:
  Can you tell me which ones?
  
 
 Multimedia apps like JACK and mplayer that use the TSC for high res
 timing need to know the CPU speed, and /proc/cpuinfo is the fast way to
 get it.
 
 Why don't you create sysfs entries instead?  It would be better to have
 all the cpuinfo contents as one value per file anyway (faster
 application startup).

Well, sounds very good. It's a chance for me to learn to program
sysfs and also to create something useful.

So the right location to place that data would be
/sys/devices/system/cpu/cpuX?

Nico

-- 
Keep it simple  stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org
-
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: PMTU, MSS and "fragmentation needed" problem with linux?

[Nico Schottelius]

Thanks for the hints Florian, but still there are open questions:

Florian Attenberger [Thu, Apr 07, 2005 at 07:33:09PM +0200]:
> [...]
> # [From the kernel help:
> #
> #This option adds a `TCPMSS' target, which allows you to alter the
> #MSS value of TCP SYN packets, to control the maximum size for that
> #connection (usually limiting it to your outgoing interface's MTU
> #minus 40).

The MTU is 1460 or 1492 in tested cases. This means on ppp0, TCPMSS
should be 1420 or maximum of 1452. Why do I see 1460 on the interface?

> #This is used to overcome criminally braindead ISPs or servers which
> #block ICMP Fragmentation Needed packets. 

That's clear to me, there are sites out there, debatting that problem.
But:

- Should not _my_ Linux-router tell _my_ client that the mtu choosen
  is too big?
- On the tested connections _all_ icmp types were allowed (disabled iptables)
- As far as I can see, the routers between the two hosts
  don't drop the generated icmp-packets

The first of the questions was the reason I choosed this ML, because I
was wondering why my client does not get the DF-Bit-set, but frag-needed
icmp-message from the linux-router.

Or did I unterstand the technique wrong?

Greetings,

Nico

-- 
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org


pgpne4MqVk060.pgp
Description: PGP signature

PMTU, MSS and "fragmentation needed" problem with linux?

[Nico Schottelius]

Hello!

[I hope this is the correct list, if not, please tell me where to ask]

The following scenario:

Linux-client <-- Ethernet --> Linux-router <-- PPPoE --> Internet.
Linux-client has MTU==1500, so the MSS is 1460.
Linux-router has MTU==1500 on eth0 and MTU=1492 on ppp0.
The MSS is set to 1452 via pppoe command line.

My question: May the MSS on ppp0 be 1460? Imho not, as

RFC 879 defines the MSS as MTU-40, which would be 1452.
But tcpdump says 1460 on ppp0.
On another box the MTU is set to 1460 and I still see packets
with MSS 1460. Is this correct?
Should not the Linux-router send the client a packet ICMP type 3,
subtype 4, Frag needed, but DF-Bit set?

I ask htis, because of a problem I  have on the first box:
If the clients have a mtu of 1500, theycannot connect
to some servers and get timeouts.

The firewall was tested with iptables of (only MASQUERADE on), so that
all icmp packets are allowed.

Thank you for any hint!

Nico

-- 
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org


pgpGZsMEOeSko.pgp
Description: PGP signature

PMTU, MSS and fragmentation needed problem with linux?

[Nico Schottelius]

Hello!

[I hope this is the correct list, if not, please tell me where to ask]

The following scenario:

Linux-client -- Ethernet -- Linux-router -- PPPoE -- Internet.
Linux-client has MTU==1500, so the MSS is 1460.
Linux-router has MTU==1500 on eth0 and MTU=1492 on ppp0.
The MSS is set to 1452 via pppoe command line.

My question: May the MSS on ppp0 be 1460? Imho not, as

RFC 879 defines the MSS as MTU-40, which would be 1452.
But tcpdump says 1460 on ppp0.
On another box the MTU is set to 1460 and I still see packets
with MSS 1460. Is this correct?
Should not the Linux-router send the client a packet ICMP type 3,
subtype 4, Frag needed, but DF-Bit set?

I ask htis, because of a problem I  have on the first box:
If the clients have a mtu of 1500, theycannot connect
to some servers and get timeouts.

The firewall was tested with iptables of (only MASQUERADE on), so that
all icmp packets are allowed.

Thank you for any hint!

Nico

-- 
Keep it simple  stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org


pgpGZsMEOeSko.pgp
Description: PGP signature

Re: PMTU, MSS and fragmentation needed problem with linux?

[Nico Schottelius]

Thanks for the hints Florian, but still there are open questions:

Florian Attenberger [Thu, Apr 07, 2005 at 07:33:09PM +0200]:
 [...]
 # [From the kernel help:
 #
 #This option adds a `TCPMSS' target, which allows you to alter the
 #MSS value of TCP SYN packets, to control the maximum size for that
 #connection (usually limiting it to your outgoing interface's MTU
 #minus 40).

The MTU is 1460 or 1492 in tested cases. This means on ppp0, TCPMSS
should be 1420 or maximum of 1452. Why do I see 1460 on the interface?

 #This is used to overcome criminally braindead ISPs or servers which
 #block ICMP Fragmentation Needed packets. 

That's clear to me, there are sites out there, debatting that problem.
But:

- Should not _my_ Linux-router tell _my_ client that the mtu choosen
  is too big?
- On the tested connections _all_ icmp types were allowed (disabled iptables)
- As far as I can see, the routers between the two hosts
  don't drop the generated icmp-packets

The first of the questions was the reason I choosed this ML, because I
was wondering why my client does not get the DF-Bit-set, but frag-needed
icmp-message from the linux-router.

Or did I unterstand the technique wrong?

Greetings,

Nico

-- 
Keep it simple  stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org


pgpne4MqVk060.pgp
Description: PGP signature

[reiserfs] 100% cpu consum - normal?

[Nico Schottelius]

Hello!

I once again tried reiserfs, this time on my ibook:

ei ~ # mkreiserfs  -V
mkreiserfs 3.6.19 (2003 www.namesys.com)

ei ~ # uname -a
Linux ei 2.6.10 #5 Sun Feb 6 17:26:47 CET 2005 ppc 750CXe PowerBook4,1 GNU/Linux

If I tar xf $big_tar (speaking about the gcc-source), my system hangs:

- no console switching
- all keyboard input is lost
- no mouse reaction
- no network response
- no display refreshing 

When doing that on my dm-crypt-jfs home partition this does not happen.
Nor does it on my xfs root partition.

Is that a normal behaviour of reiserfs 3.6?

Greetings,

Nico

P.S.: I never assumed reiserfs will ever be a stable filesystem, but this
  is the worst result I have with it. Perhaps I am missing
  some tuning/mount option?

PPS: Please CC and confirm, I am not subscribed.

-- 
Keep it simple & stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org


pgpIXthoLmA1X.pgp
Description: PGP signature

[reiserfs] 100% cpu consum - normal?

[Nico Schottelius]

Hello!

I once again tried reiserfs, this time on my ibook:

ei ~ # mkreiserfs  -V
mkreiserfs 3.6.19 (2003 www.namesys.com)

ei ~ # uname -a
Linux ei 2.6.10 #5 Sun Feb 6 17:26:47 CET 2005 ppc 750CXe PowerBook4,1 GNU/Linux

If I tar xf $big_tar (speaking about the gcc-source), my system hangs:

- no console switching
- all keyboard input is lost
- no mouse reaction
- no network response
- no display refreshing 

When doing that on my dm-crypt-jfs home partition this does not happen.
Nor does it on my xfs root partition.

Is that a normal behaviour of reiserfs 3.6?

Greetings,

Nico

P.S.: I never assumed reiserfs will ever be a stable filesystem, but this
  is the worst result I have with it. Perhaps I am missing
  some tuning/mount option?

PPS: Please CC and confirm, I am not subscribed.

-- 
Keep it simple  stupid, use what's available.
Please use pgp encryption: 8D0E 27A4 is my id.
http://nico.schotteli.us | http://linux.schottelius.org


pgpIXthoLmA1X.pgp
Description: PGP signature

Re: [NO-PATCH] compile error: 2.6.10 / megaraid_mbox

[Nico Schottelius]

Hello Again!

Sorry Greg for the wrong information. The kernel I modified
had been patched with some megaraid patches before. I wasn't
told that it was patched. I retested it with 2.6.10 and it works
fine!

So keep on good work,

Nico
-
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-PATCH] compile error: 2.6.10 / megaraid_mbox

[Nico Schottelius]

Hello Again!

Sorry Greg for the wrong information. The kernel I modified
had been patched with some megaraid patches before. I wasn't
told that it was patched. I retested it with 2.6.10 and it works
fine!

So keep on good work,

Nico
-
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/

[PATCH] compile error: 2.6.10 / megaraid_mbox

[Nico Schottelius]

Good morning!

I was trying to compile Megaraid on 2.6.10 and
noticed that pci_dma_sync_single and pci_dma_sync_sg
are deprecated. Greg seems to tried to patch it in 2.6.9
(http://lkml.org/lkml/2004/10/19/425), but it seems he didn't catch it
all.

A patch against vanialla 2.6.10 is attached.


Greetings,

Nico

--- megaraid_mbox.c.orig2005-02-07 14:57:16.0 +0100
+++ megaraid_mbox.c 2005-02-07 15:03:00.0 +0100
@@ -1554,12 +1554,12 @@
 
if (scb->dma_direction == PCI_DMA_TODEVICE) {
if (!scb->scp->use_sg) {// sg list not used
-   pci_dma_sync_single(adapter->pdev, ccb->buf_dma_h,
+   pci_dma_sync_single_for_cpu(adapter->pdev, 
ccb->buf_dma_h,
scb->scp->request_bufflen,
PCI_DMA_TODEVICE);
}
else {
-   pci_dma_sync_sg(adapter->pdev, scb->scp->request_buffer,
+   pci_dma_sync_sg_for_cpu(adapter->pdev, 
scb->scp->request_buffer,
scb->scp->use_sg, PCI_DMA_TODEVICE);
}
}
@@ -2332,7 +2332,7 @@
 
case MRAID_DMA_WBUF:
if (scb->dma_direction == PCI_DMA_FROMDEVICE) {
-   pci_dma_sync_single(adapter->pdev,
+   pci_dma_sync_single_for_cpu(adapter->pdev,
ccb->buf_dma_h,
scb->scp->request_bufflen,
PCI_DMA_FROMDEVICE);
@@ -2345,7 +2345,7 @@
 
case MRAID_DMA_WSG:
if (scb->dma_direction == PCI_DMA_FROMDEVICE) {
-   pci_dma_sync_sg(adapter->pdev,
+   pci_dma_sync_sg_for_cpu(adapter->pdev,
scb->scp->request_buffer,
scb->scp->use_sg, PCI_DMA_FROMDEVICE);
}

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

[PATCH] compile error: 2.6.10 / megaraid_mbox

[Nico Schottelius]

Good morning!

I was trying to compile Megaraid on 2.6.10 and
noticed that pci_dma_sync_single and pci_dma_sync_sg
are deprecated. Greg seems to tried to patch it in 2.6.9
(http://lkml.org/lkml/2004/10/19/425), but it seems he didn't catch it
all.

A patch against vanialla 2.6.10 is attached.


Greetings,

Nico

--- megaraid_mbox.c.orig2005-02-07 14:57:16.0 +0100
+++ megaraid_mbox.c 2005-02-07 15:03:00.0 +0100
@@ -1554,12 +1554,12 @@
 
if (scb-dma_direction == PCI_DMA_TODEVICE) {
if (!scb-scp-use_sg) {// sg list not used
-   pci_dma_sync_single(adapter-pdev, ccb-buf_dma_h,
+   pci_dma_sync_single_for_cpu(adapter-pdev, 
ccb-buf_dma_h,
scb-scp-request_bufflen,
PCI_DMA_TODEVICE);
}
else {
-   pci_dma_sync_sg(adapter-pdev, scb-scp-request_buffer,
+   pci_dma_sync_sg_for_cpu(adapter-pdev, 
scb-scp-request_buffer,
scb-scp-use_sg, PCI_DMA_TODEVICE);
}
}
@@ -2332,7 +2332,7 @@
 
case MRAID_DMA_WBUF:
if (scb-dma_direction == PCI_DMA_FROMDEVICE) {
-   pci_dma_sync_single(adapter-pdev,
+   pci_dma_sync_single_for_cpu(adapter-pdev,
ccb-buf_dma_h,
scb-scp-request_bufflen,
PCI_DMA_FROMDEVICE);
@@ -2345,7 +2345,7 @@
 
case MRAID_DMA_WSG:
if (scb-dma_direction == PCI_DMA_FROMDEVICE) {
-   pci_dma_sync_sg(adapter-pdev,
+   pci_dma_sync_sg_for_cpu(adapter-pdev,
scb-scp-request_buffer,
scb-scp-use_sg, PCI_DMA_FROMDEVICE);
}

-
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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

> The manual for my C1536A says:
>
> | The C1536A does not support termination on the device itself. Normally, the
> | unit will not be placed at the end of a bus. However, if this is
> | unavoidable, we recommend the use of an additional length of cable with a
> | terminator attached. (Lack of space does not allow for a feed-through
> | connector to be used to the drive.)
>
> | Terminator: Methode Active SCSI Terminator DM1050-02-R
> | Methode Passive SCSI Terminator DM1050-02-0
>
> So you should get a terminator (or an addtional SCSI device that does have a
> termination dipswitch/jumper, like my CD-ROM drive :-)
>
> This also explains why it works without the C1536: in that case your SCSI host
> adapter will auto-terminate the empty narrow chain.

Thank you Geert!

That was the informations I needed all the time!
So I ordered an active terminator yesterday.

Nico

-
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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

 The manual for my C1536A says:

 | The C1536A does not support termination on the device itself. Normally, the
 | unit will not be placed at the end of a bus. However, if this is
 | unavoidable, we recommend the use of an additional length of cable with a
 | terminator attached. (Lack of space does not allow for a feed-through
 | connector to be used to the drive.)

 | Terminator: Methode Active SCSI Terminator DM1050-02-R
 | Methode Passive SCSI Terminator DM1050-02-0

 So you should get a terminator (or an addtional SCSI device that does have a
 termination dipswitch/jumper, like my CD-ROM drive :-)

 This also explains why it works without the C1536: in that case your SCSI host
 adapter will auto-terminate the empty narrow chain.

Thank you Geert!

That was the informations I needed all the time!
So I ordered an active terminator yesterday.

Nico

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

ipchains autoload

[Nico Schottelius]

Hello!

I don't really know howto specify that kmod
should autoload the ipchains module, when I am
using ipchains.

Anyone any idea howto tell kmod to load it then ?


Nico

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

ipchains autoload

[Nico Schottelius]

Hello!

I don't really know howto specify that kmod
should autoload the ipchains module, when I am
using ipchains.

Anyone any idea howto tell kmod to load it then ?


Nico

-
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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Khalid Aziz wrote:

> Nico Schottelius wrote:
> >
> > Hi all!
> >
> > The problem is solved, if I disconnect the hp streamer
> > from the bus. I wonder why there is a problem.
> > The aic7880 has two busses:
> >
> > ultra/ ultrawide.
> >
> > The ibm hard disk is connected to the uw port and is terminated.
> > No other uw device is attached.
> >
> > The hp streamer is also lonely on the ultra bus. I have
> > no documentation for that device, so I don't know
> > whether it is terminated nor if it is using parity.
> >
> > Btw, can somebody explain what the parity bit does to me ?
> >
> > Or does anybody have a hp c1536 streamer and can help me ?
>
> Based upon the lspci output you posted earlier, aic7880 has a single
> SCSI bus.

Oh. That could really be a problem.. I though having two different
connectors on the board would make two different buses..
I must have been wrong.

> So you must mean two internal connectors. Both of your devices
> (HD and Tape) do show up on the same bus during scan. Since you have
> connected devices to both connectors on the card, you must terminate
> both devices.

Okay, so far I understood.

> Sounds like you HD might be terminated.

It is.

> You need to terminate tape drive as well.

It seems like it is impossible:

> I do not have a C1536 handy,

the problem is I do have :)

> but if you look at the back of the drive you should see 10 pins aligned
> horizontally.

No. And that's the real problem.
I can see the following:

2 - 1 -0 for the id (every one with two pins), NC (one pin).
Under the device is a small claviar.
I mean a small think, a bank with small switches on it.

reading from left to right:
1 - 2 -3 -  4 -5 -6 -7 -8.
If the switch is up, it is on.

--
| o  |   on
| |
--

--
|  |   off.
| o  |
--

I hope you understand what I mean to say with thoses ascii figures.

Does anybody know what to do with these
switches ?

Nico

ps: oh, you are from hp, that's the reason why you know so much about this
device ;)


> They should all be labelled on the back panel and most
> likely are (from left to right) - TP, 2, 1, 0, NC. TP is the pair of
> Term Power Enable pins. Place a jumper over the leftmost two pins to
> enable termination on the drive and try again.
>
> --
> Khalid
>
> 
> Khalid Aziz Linux Development Laboratory
> (970)898-9214Hewlett-Packard
> [EMAIL PROTECTED]Fort Collins, CO
>
> Disclaimer: I do not speak for HP. These are my personal opinions.

-
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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Hi all!

The problem is solved, if I disconnect the hp streamer
from the bus. I wonder why there is a problem.
The aic7880 has two busses:

ultra/ ultrawide.

The ibm hard disk is connected to the uw port and is terminated.
No other uw device is attached.

The hp streamer is also lonely on the ultra bus. I have
no documentation for that device, so I don't know
whether it is terminated nor if it is using parity.

Btw, can somebody explain what the parity bit does to me ?

Or does anybody have a hp c1536 streamer and can help me ?


Regards,

Nico

-
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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

> >  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> >  I/O error: dev 08:01, sector 127304
> > SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
> > [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
> > ASC=47 ASCQ= 0
> > Raw sense data:0x70 0x00 0x0b 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x47 
>0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
>0x00 0x00
> >  I/O error: dev 08:01, sector 127312
> > SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
> > [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
> > ASC=47 ASCQ= 0
>
> You are seeing lots of parity errors (ASC=47 ASCQ=0). I would suggest
> checking cabling and terminator.

There is in fact no terminator, the scsi disc should terminate the bus
itself. It is directly connected to the onboard aix7880 scsi controller.
I will use another cable in about half an hour (when my friend arrives..)

Thanks for the hint!

Nico

-
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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Guest section DW wrote:

> On Thu, Jun 07, 2001 at 06:22:59PM +0200, Nico Schottelius wrote:
>
> >  0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> >  I/O error: dev 08:01, sector 127304
> > SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
> > [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
> > ASC=47 ASCQ= 0
> > Raw sense data:0x70 0x00 0x0b 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x47 
>0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
>0x00 0x00
> >  I/O error: dev 08:01, sector 127312
>
> Aborted command: SCSI parity error.

Hmm...what to do against this ?
the 'disable parity' jumper is not set, should I set it ?

Or was this something to adjust in the boot up adaptec
menu ?

Whatever, thanks a lot to here !

Nico

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

scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Hello guys!

Currently my scsi disc is only reporting errors!
In the adaptect scsi bios I tried the verify media
option and it worked fine. The output from the Linux
kernel is more than worse!

Can you tell me what's wrong in my system ?

I will monitor the mailing list the next hours, if
the hard disk allows that.

Please help me, this is the second scsi disc
reporting such failures!

Regards,

Nico


 Scsiinfo version 1.7(eowmob)

Inquiry command
---
Relative Address   0
Wide bus 320
Wide bus 161
Synchronous neg.   1
Linked Commands1
Command Queueing   1
SftRe  0
Device Type0
Peripheral Qualifier   0
Removable? 0
Device Type Modifier   0
ISO Version0
ECMA Version   0
ANSI Version   3
AENC   0
TrmIOP 0
Response Data Format   2
Vendor:IBM 
Product:   DNES-309170W
Revision level:SA30AJGE0980

Serial Number 'AJGE0980'
Data from Rigid Disk Drive Geometry Page

Number of cylinders11474
Number of heads5
Starting write precomp 0
Starting reduced current   0
Drive step rate0
Landing Zone Cylinder  0
RPL0
Rotational Offset  0
Rotational Rate7200

Data from Caching Page
--
Write Cache1
Read Cache 1
Prefetch units 0
Demand Read Retention Priority 0
Demand Write Retention Priority0
Disable Pre-fetch Transfer Length  65535
Minimum Pre-fetch  0
Maximum Pre-fetch  65535
Maximum Pre-fetch Ceiling  65535

Data from Format Device Page

Removable Medium   0
Supports Hard Sectoring1
Supports Soft Sectoring0
Addresses assigned by surface  0
Tracks per Zone5215
Alternate sectors per zone 0
Alternate tracks per zone  0
Alternate tracks per lun   0
Sectors per track  320
Bytes per sector   512
Interleave 1
Track skew factor  11
Cylinder skew factor   20

Data from Error Recovery Page
-
AWRE   1
ARRE   1
TB 0
RC 0
EER0
PER0
DTE0
DCR0
Read Retry Count   1
Correction Span0
Head Offset Count  0
Data Strobe Offset Count   0
Write Retry Count  1
Recovery Time Limit0

Data from Control Page
--
RLEC   0
QErr   0
DQue   0
EECA   0
RAENP  0
UUAENP 0
EAENP  0
Queue Algorithm Modifier   0
Ready AEN Holdoff Period   0

Data from Disconnect-Reconnect Page
---
Buffer full ratio  0
Buffer empty ratio 0
Bus Inactivity Limit   0
Disconnect Time Limit  0
Connect Time Limit 0
Maximum Burst Size 0
DTDC   0x0

Data from Defect Lists
--
151 entries in manufacturer table.
Format is: bytes from index [Cyl:Head:Off]
Offset -1 marks whole track as bad.

 137:3:70656 138:3:70656 139:3:70656 140:3:70656 141:3:70656
186:1:182272 367:4:92672382:0:122880382:0:123392 434:4:47104
 454:4:47104 458:4:47104 459:4:47104 460:4:47104 461:4:47104
 462:4:47104558:1:109056559:1:109056560:1:109056561:1:109056
 733:1:40960  1086:2:5121110:1:834561110:1:83968 1139:1:9216
1251:4:68608   1733:1:115712   1854:0:1484801926:Unable to read Peripheral 
Device Page 09h
1:199681940:4:82944
1974:1:112642156:1:404482440:1:486402497:1:78848   3416:0:146432
   3669:1:110592   3669:1:04   3669:1:111616   3669:1:112128   3669:1:112640
   3669:1:113152   3669:1:113664   3669:1:114176   3669:1:114688   3669:1:115200
   3669:1:115712   3669:1:116224   3669:1:116736   3669:1:1172484125:4:27136
   4142:4:126464   4222:1:1459204371:2:86528   4437:3:144384

scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Hello guys!

Currently my scsi disc is only reporting errors!
In the adaptect scsi bios I tried the verify media
option and it worked fine. The output from the Linux
kernel is more than worse!

Can you tell me what's wrong in my system ?

I will monitor the mailing list the next hours, if
the hard disk allows that.

Please help me, this is the second scsi disc
reporting such failures!

Regards,

Nico


 Scsiinfo version 1.7(eowmob)

Inquiry command
---
Relative Address   0
Wide bus 320
Wide bus 161
Synchronous neg.   1
Linked Commands1
Command Queueing   1
SftRe  0
Device Type0
Peripheral Qualifier   0
Removable? 0
Device Type Modifier   0
ISO Version0
ECMA Version   0
ANSI Version   3
AENC   0
TrmIOP 0
Response Data Format   2
Vendor:IBM 
Product:   DNES-309170W
Revision level:SA30AJGE0980

Serial Number 'AJGE0980'
Data from Rigid Disk Drive Geometry Page

Number of cylinders11474
Number of heads5
Starting write precomp 0
Starting reduced current   0
Drive step rate0
Landing Zone Cylinder  0
RPL0
Rotational Offset  0
Rotational Rate7200

Data from Caching Page
--
Write Cache1
Read Cache 1
Prefetch units 0
Demand Read Retention Priority 0
Demand Write Retention Priority0
Disable Pre-fetch Transfer Length  65535
Minimum Pre-fetch  0
Maximum Pre-fetch  65535
Maximum Pre-fetch Ceiling  65535

Data from Format Device Page

Removable Medium   0
Supports Hard Sectoring1
Supports Soft Sectoring0
Addresses assigned by surface  0
Tracks per Zone5215
Alternate sectors per zone 0
Alternate tracks per zone  0
Alternate tracks per lun   0
Sectors per track  320
Bytes per sector   512
Interleave 1
Track skew factor  11
Cylinder skew factor   20

Data from Error Recovery Page
-
AWRE   1
ARRE   1
TB 0
RC 0
EER0
PER0
DTE0
DCR0
Read Retry Count   1
Correction Span0
Head Offset Count  0
Data Strobe Offset Count   0
Write Retry Count  1
Recovery Time Limit0

Data from Control Page
--
RLEC   0
QErr   0
DQue   0
EECA   0
RAENP  0
UUAENP 0
EAENP  0
Queue Algorithm Modifier   0
Ready AEN Holdoff Period   0

Data from Disconnect-Reconnect Page
---
Buffer full ratio  0
Buffer empty ratio 0
Bus Inactivity Limit   0
Disconnect Time Limit  0
Connect Time Limit 0
Maximum Burst Size 0
DTDC   0x0

Data from Defect Lists
--
151 entries in manufacturer table.
Format is: bytes from index [Cyl:Head:Off]
Offset -1 marks whole track as bad.

 137:3:70656 138:3:70656 139:3:70656 140:3:70656 141:3:70656
186:1:182272 367:4:92672382:0:122880382:0:123392 434:4:47104
 454:4:47104 458:4:47104 459:4:47104 460:4:47104 461:4:47104
 462:4:47104558:1:109056559:1:109056560:1:109056561:1:109056
 733:1:40960  1086:2:5121110:1:834561110:1:83968 1139:1:9216
1251:4:68608   1733:1:115712   1854:0:1484801926:Unable to read Peripheral 
Device Page 09h
1:199681940:4:82944
1974:1:112642156:1:404482440:1:486402497:1:78848   3416:0:146432
   3669:1:110592   3669:1:04   3669:1:111616   3669:1:112128   3669:1:112640
   3669:1:113152   3669:1:113664   3669:1:114176   3669:1:114688   3669:1:115200
   3669:1:115712   3669:1:116224   3669:1:116736   3669:1:1172484125:4:27136
   4142:4:126464   4222:1:1459204371:2:86528   4437:3:144384

Re: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Guest section DW wrote:

 On Thu, Jun 07, 2001 at 06:22:59PM +0200, Nico Schottelius wrote:

   0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
   I/O error: dev 08:01, sector 127304
  SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
  [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
  ASC=47 ASCQ= 0
  Raw sense data:0x70 0x00 0x0b 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x47 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00
   I/O error: dev 08:01, sector 127312

 Aborted command: SCSI parity error.

Hmm...what to do against this ?
the 'disable parity' jumper is not set, should I set it ?

Or was this something to adjust in the boot up adaptec
menu ?

Whatever, thanks a lot to here !

Nico

-
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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

   0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
   I/O error: dev 08:01, sector 127304
  SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
  [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
  ASC=47 ASCQ= 0
  Raw sense data:0x70 0x00 0x0b 0x00 0x00 0x00 0x00 0x18 0x00 0x00 0x00 0x00 0x47 
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 
0x00 0x00
   I/O error: dev 08:01, sector 127312
  SCSI disk error : host 0 channel 0 id 0 lun 0 return code = 802
  [valid=0] Info fld=0x0, Current sd08:01: sns = 70  b
  ASC=47 ASCQ= 0

 You are seeing lots of parity errors (ASC=47 ASCQ=0). I would suggest
 checking cabling and terminator.

There is in fact no terminator, the scsi disc should terminate the bus
itself. It is directly connected to the onboard aix7880 scsi controller.
I will use another cable in about half an hour (when my friend arrives..)

Thanks for the hint!

Nico

-
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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Hi all!

The problem is solved, if I disconnect the hp streamer
from the bus. I wonder why there is a problem.
The aic7880 has two busses:

ultra/ ultrawide.

The ibm hard disk is connected to the uw port and is terminated.
No other uw device is attached.

The hp streamer is also lonely on the ultra bus. I have
no documentation for that device, so I don't know
whether it is terminated nor if it is using parity.

Btw, can somebody explain what the parity bit does to me ?

Or does anybody have a hp c1536 streamer and can help me ?


Regards,

Nico

-
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: scsi disk defect or kernel driver defect ?

[Nico Schottelius]

Khalid Aziz wrote:

 Nico Schottelius wrote:
 
  Hi all!
 
  The problem is solved, if I disconnect the hp streamer
  from the bus. I wonder why there is a problem.
  The aic7880 has two busses:
 
  ultra/ ultrawide.
 
  The ibm hard disk is connected to the uw port and is terminated.
  No other uw device is attached.
 
  The hp streamer is also lonely on the ultra bus. I have
  no documentation for that device, so I don't know
  whether it is terminated nor if it is using parity.
 
  Btw, can somebody explain what the parity bit does to me ?
 
  Or does anybody have a hp c1536 streamer and can help me ?

 Based upon the lspci output you posted earlier, aic7880 has a single
 SCSI bus.

Oh. That could really be a problem.. I though having two different
connectors on the board would make two different buses..
I must have been wrong.

 So you must mean two internal connectors. Both of your devices
 (HD and Tape) do show up on the same bus during scan. Since you have
 connected devices to both connectors on the card, you must terminate
 both devices.

Okay, so far I understood.

 Sounds like you HD might be terminated.

It is.

 You need to terminate tape drive as well.

It seems like it is impossible:

 I do not have a C1536 handy,

the problem is I do have :)

 but if you look at the back of the drive you should see 10 pins aligned
 horizontally.

No. And that's the real problem.
I can see the following:

2 - 1 -0 for the id (every one with two pins), NC (one pin).
Under the device is a small claviar.
I mean a small think, a bank with small switches on it.

reading from left to right:
1 - 2 -3 -  4 -5 -6 -7 -8.
If the switch is up, it is on.

--
| o  |   on
| |
--

--
|  |   off.
| o  |
--

I hope you understand what I mean to say with thoses ascii figures.

Does anybody know what to do with these
switches ?

Nico

ps: oh, you are from hp, that's the reason why you know so much about this
device ;)


 They should all be labelled on the back panel and most
 likely are (from left to right) - TP, 2, 1, 0, NC. TP is the pair of
 Term Power Enable pins. Place a jumper over the leftmost two pins to
 enable termination on the drive and try again.

 --
 Khalid

 
 Khalid Aziz Linux Development Laboratory
 (970)898-9214Hewlett-Packard
 [EMAIL PROTECTED]Fort Collins, CO

 Disclaimer: I do not speak for HP. These are my personal opinions.

-
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 ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

[Nico Schottelius]

Daniel Phillips wrote:

> On Wednesday 30 May 2001 17:25, Ingo Molnar wrote:
> > On Wed, 30 May 2001, Nico Schottelius wrote:
> > > > the default value is 0, that is good enough.
> > >
> > > hmm.. I don't think so... value of 1 would be much better, because
> > > 0 normally disables the speaker.
> >
> > i confused the value. Yes, an initialization to 1 would be the
> > correct, ie.:
> >
> > +++ linux-2.4.5-nc/kernel/sysctl.c  Wed May  9 23:44:30 2001
> > @@ -48,6 +49,7 @@
> >  extern int nr_queued_signals, max_queued_signals;
> >  extern int sysrq_enabled;
> >
> > +int pcspeaker_enabled = 1;
>
> I'd go and change the whole patch so that speaker_disabled = 0 is the
> default, but that's just me.

Hmm...I thinking positive is more likely for humans, and double
negotation, like "not_disable" is less taken than just "enable".

So I agree with ingo, just setting pcspeaker_enabled = 1 at
normal would be the very best way.

Just after discussing about that, is it possible
someone adds the final patch ?


Nico

-
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 ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

[Nico Schottelius]

Daniel Phillips wrote:

 On Wednesday 30 May 2001 17:25, Ingo Molnar wrote:
  On Wed, 30 May 2001, Nico Schottelius wrote:
the default value is 0, that is good enough.
  
   hmm.. I don't think so... value of 1 would be much better, because
   0 normally disables the speaker.
 
  i confused the value. Yes, an initialization to 1 would be the
  correct, ie.:
 
  +++ linux-2.4.5-nc/kernel/sysctl.c  Wed May  9 23:44:30 2001
  @@ -48,6 +49,7 @@
   extern int nr_queued_signals, max_queued_signals;
   extern int sysrq_enabled;
 
  +int pcspeaker_enabled = 1;

 I'd go and change the whole patch so that speaker_disabled = 0 is the
 default, but that's just me.

Hmm...I thinking positive is more likely for humans, and double
negotation, like not_disable is less taken than just enable.

So I agree with ingo, just setting pcspeaker_enabled = 1 at
normal would be the very best way.

Just after discussing about that, is it possible
someone adds the final patch ?


Nico

-
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 ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

[Nico Schottelius]

> > less code / one int more in the kernel
> > or
> > more code and #ifs / one int less in the kernel
>
> if the #ifdefs bloat the code 4 times the size of the simple patch, then
> we obviously want 4 bytes more in the kernel.

Okay.

> > And what about the code from kernel/sys.c ? The version you provided
> > doesn't take care of what's the default value of pcspeaker. This would
> > make it undefined, which is not really good.
>
> the default value is 0, that is good enough.

hmm.. I don't think so... value of 1 would be much better, because
0 normally disables the speaker.
So setting somewhere pcspeaker_enabled = 1 should be better
than having it with 0.

So in kernel/sysctl.c:

int pcspeaker_enabled = 1;

or anybody against this ?

Nico


-
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 ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

[Nico Schottelius]

Hi!


Where did you put the config.in entries to ?
This way it would be enabled all the time... okay...
I like that, too.
In the version I set up, I used the config.in entries,
because if you use disable pc_speaker, there is at
least one more int in the kernel. This is surely now much,
but as it is not needed all the time, I thought about choosing it
from menuconfig/config/...

So in short:

less code / one int more in the kernel
or
more code and #ifs / one int less in the kernel

What do you think is better ? I agree that the above one
is nicer code, but in fact I would prefer the second solution.

And what about the code from kernel/sys.c ?
The version you provided doesn't take care of what's
the default value of pcspeaker. This would make it
undefined, which is not really good.

Regards,

Nico
-
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: unresolved symbols printk ?

[Nico Schottelius]

Hmm guys, my machine
doesn't even work after I made mrproper and all the things!
It is still the same old message with unresolved symbols!
What to do now ?

Nico

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

[ PATCH ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

[Nico Schottelius]

Hello!

As I read that Alan and Linus are more than busy,
I just retry sending the patch to the list.

The patch allows you to switch off the builtin pc speaker
with sysctl options. No program will then be able to
beep under Linux, nor under X neither in the console.

Normally the speaker keeps enabled, unless you

echo 0 > /proc/sys/kernel/pcspeaker

With all values != 0 it is turned on (documented is 1).

The support is included for i386, ia64, alpha, mips and mips64.

It is tested under i386 with several kernels / machines.
No problem occurs.
The code should not make any problems on the other
processors, but I would be nice if I could get feedback
from people using this on alpha,...

I (and maybe others ?) would be happy if someone
applies the patch to 2.4.6.

Thank you,

Nico

P.S.: I also attached an init script. This is from the clinux
distrubtion
and has to be changed to run without /etc/sys/combined and
/etc/sys/boot/kernelsettings.
If somebody is interested, I can send him/her the /etc/sys/ files.




#!/bin/sh
# 
# Author: Nico Schottelius 
# Date: 15th of May 2k+1
# Last Changed: 15th of May 2k+1
# Comment: Sub script of kernel/ settings script. Set pcspeaker on/off
#

. /etc/sys/combined
. /etc/sys/boot/kernelsettings

case "$1" in
on) $SYS_ECHO -n "$SET $PC_SPEAKER_TEXT $WILL_TEXT "
echo 1 > $PC_SPEAKER_FILE
$SYS_ECHO $ON
;;
off)$SYS_ECHO -n "$SET $PC_SPEAKER_TEXT $WILL_TEXT "
echo 0 > $PC_SPEAKER_FILE
$SYS_ECHO $OFF
;;

status) $SYS_ECHO -n "$STATUS $PC_SPEAKER_TEXT $IS_TEXT "
if [ `cat $PC_SPEAKER_FILE` -eq 0 ]; then
$SYS_ECHO $OFF
else
$SYS_ECHO $ON
fi
;;
*)  $SYS_ECHO  "$USAGE $0 {on|off|status}"
exit 1
esac

exit 0




diff -u --recursive linux-2.4.5/Documentation/Configure.help 
linux-2.4.5-nc/Documentation/Configure.help
--- linux-2.4.5/Documentation/Configure.helpTue May 29 17:56:15 2001
+++ linux-2.4.5-nc/Documentation/Configure.help Mon May 28 19:23:47 2001
@@ -333,6 +333,23 @@
 
   Most users will answer N here.
 
+Disables the PC or internal speaker
+CONFIG_DISABLE_PC_SPEAKER
+  Whenever you don't want your computer to be able to beep,
+  choose this option. Actually, choosing this will still not
+  disable the speaker, you have to use sysctl for this:
+
+ echo 0 > /proc/sys/kernel/pcspeaker # disable speaker
+
+ echo 1 > /proc/sys/kernel/pcspeaker # enable speaker (default)
+
+  Attention: This will not catch the beeps made directly by the
+  BIOS (mostly this happens when using a notebook and pressing
+  special key codes). To disable this "BIOS-beep" enter the
+  BIOS and change it there.
+
+  If you are unsure, say N.
+
 Network Block Device support
 CONFIG_BLK_DEV_NBD
   Saying Y here will allow your computer to be a client for network
diff -u --recursive linux-2.4.5/arch/alpha/config.in 
linux-2.4.5-nc/arch/alpha/config.in
--- linux-2.4.5/arch/alpha/config.inTue May 29 17:56:15 2001
+++ linux-2.4.5-nc/arch/alpha/config.in Tue May 29 18:37:02 2001
@@ -240,6 +240,11 @@
 tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC
 tristate 'Kernel support for Linux/Intel ELF binaries' CONFIG_BINFMT_EM86
 source drivers/parport/Config.in
+
+if [ "$CONFIG_SYSCTL" = "y" ]; then
+   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
+fi
+
 endmenu
 
 source drivers/mtd/Config.in
diff -u --recursive linux-2.4.5/arch/arm/config.in linux-2.4.5-nc/arch/arm/config.in
--- linux-2.4.5/arch/arm/config.in  Tue May 29 17:55:36 2001
+++ linux-2.4.5-nc/arch/arm/config.in   Tue May 29 18:49:17 2001
@@ -372,6 +372,12 @@
source net/ax25/Config.in
 
source net/irda/Config.in
+
+if [ "$CONFIG_SYSCTL" = "y" ]; then
+   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
+fi
+
 fi
 
 mainmenu_option next_comment
diff -u --recursive linux-2.4.5/arch/i386/config.in linux-2.4.5-nc/arch/i386/config.in
--- linux-2.4.5/arch/i386/config.in Tue May 29 17:56:16 2001
+++ linux-2.4.5-nc/arch/i386/config.in  Tue May 29 18:36:20 2001
@@ -258,6 +258,10 @@
bool 'Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
 fi
 
+if [ "$CONFIG_SYSCTL" = "y" ]; then
+   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
+fi
+
 endmenu
 
 source drivers/mtd/Config.in
diff -u --recursive linux-2.4.5/arch/ia64/config.in linux-2.4.5-nc/arch/ia64/config.in
--- linux-2.4.5/arch/ia64/config.in Tue May 29 17:55:36 2001
+++ linux-2.4.5-nc/arch/ia64/config.in  Tue May 29 18:41:58 2001
@@ -137,6 +137,10 @@
 
 fi # !HP_SIM
 
+if [ "$CONFIG_SYSCTL" = "y" ]; then
+   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
+fi
+
 e

[ PATCH ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

[Nico Schottelius]

Hello!

As I read that Alan and Linus are more than busy,
I just retry sending the patch to the list.

The patch allows you to switch off the builtin pc speaker
with sysctl options. No program will then be able to
beep under Linux, nor under X neither in the console.

Normally the speaker keeps enabled, unless you

echo 0  /proc/sys/kernel/pcspeaker

With all values != 0 it is turned on (documented is 1).

The support is included for i386, ia64, alpha, mips and mips64.

It is tested under i386 with several kernels / machines.
No problem occurs.
The code should not make any problems on the other
processors, but I would be nice if I could get feedback
from people using this on alpha,...

I (and maybe others ?) would be happy if someone
applies the patch to 2.4.6.

Thank you,

Nico

P.S.: I also attached an init script. This is from the clinux
distrubtion
and has to be changed to run without /etc/sys/combined and
/etc/sys/boot/kernelsettings.
If somebody is interested, I can send him/her the /etc/sys/ files.




#!/bin/sh
# 
# Author: Nico Schottelius nico AT schottelius DOT org
# Date: 15th of May 2k+1
# Last Changed: 15th of May 2k+1
# Comment: Sub script of kernel/ settings script. Set pcspeaker on/off
#

. /etc/sys/combined
. /etc/sys/boot/kernelsettings

case $1 in
on) $SYS_ECHO -n $SET $PC_SPEAKER_TEXT $WILL_TEXT 
echo 1  $PC_SPEAKER_FILE
$SYS_ECHO $ON
;;
off)$SYS_ECHO -n $SET $PC_SPEAKER_TEXT $WILL_TEXT 
echo 0  $PC_SPEAKER_FILE
$SYS_ECHO $OFF
;;

status) $SYS_ECHO -n $STATUS $PC_SPEAKER_TEXT $IS_TEXT 
if [ `cat $PC_SPEAKER_FILE` -eq 0 ]; then
$SYS_ECHO $OFF
else
$SYS_ECHO $ON
fi
;;
*)  $SYS_ECHO  $USAGE $0 {on|off|status}
exit 1
esac

exit 0




diff -u --recursive linux-2.4.5/Documentation/Configure.help 
linux-2.4.5-nc/Documentation/Configure.help
--- linux-2.4.5/Documentation/Configure.helpTue May 29 17:56:15 2001
+++ linux-2.4.5-nc/Documentation/Configure.help Mon May 28 19:23:47 2001
@@ -333,6 +333,23 @@
 
   Most users will answer N here.
 
+Disables the PC or internal speaker
+CONFIG_DISABLE_PC_SPEAKER
+  Whenever you don't want your computer to be able to beep,
+  choose this option. Actually, choosing this will still not
+  disable the speaker, you have to use sysctl for this:
+
+ echo 0  /proc/sys/kernel/pcspeaker # disable speaker
+
+ echo 1  /proc/sys/kernel/pcspeaker # enable speaker (default)
+
+  Attention: This will not catch the beeps made directly by the
+  BIOS (mostly this happens when using a notebook and pressing
+  special key codes). To disable this BIOS-beep enter the
+  BIOS and change it there.
+
+  If you are unsure, say N.
+
 Network Block Device support
 CONFIG_BLK_DEV_NBD
   Saying Y here will allow your computer to be a client for network
diff -u --recursive linux-2.4.5/arch/alpha/config.in 
linux-2.4.5-nc/arch/alpha/config.in
--- linux-2.4.5/arch/alpha/config.inTue May 29 17:56:15 2001
+++ linux-2.4.5-nc/arch/alpha/config.in Tue May 29 18:37:02 2001
@@ -240,6 +240,11 @@
 tristate 'Kernel support for MISC binaries' CONFIG_BINFMT_MISC
 tristate 'Kernel support for Linux/Intel ELF binaries' CONFIG_BINFMT_EM86
 source drivers/parport/Config.in
+
+if [ $CONFIG_SYSCTL = y ]; then
+   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
+fi
+
 endmenu
 
 source drivers/mtd/Config.in
diff -u --recursive linux-2.4.5/arch/arm/config.in linux-2.4.5-nc/arch/arm/config.in
--- linux-2.4.5/arch/arm/config.in  Tue May 29 17:55:36 2001
+++ linux-2.4.5-nc/arch/arm/config.in   Tue May 29 18:49:17 2001
@@ -372,6 +372,12 @@
source net/ax25/Config.in
 
source net/irda/Config.in
+
+if [ $CONFIG_SYSCTL = y ]; then
+   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
+fi
+
 fi
 
 mainmenu_option next_comment
diff -u --recursive linux-2.4.5/arch/i386/config.in linux-2.4.5-nc/arch/i386/config.in
--- linux-2.4.5/arch/i386/config.in Tue May 29 17:56:16 2001
+++ linux-2.4.5-nc/arch/i386/config.in  Tue May 29 18:36:20 2001
@@ -258,6 +258,10 @@
bool 'Use real mode APM BIOS call to power off' CONFIG_APM_REAL_MODE_POWER_OFF
 fi
 
+if [ $CONFIG_SYSCTL = y ]; then
+   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
+fi
+
 endmenu
 
 source drivers/mtd/Config.in
diff -u --recursive linux-2.4.5/arch/ia64/config.in linux-2.4.5-nc/arch/ia64/config.in
--- linux-2.4.5/arch/ia64/config.in Tue May 29 17:55:36 2001
+++ linux-2.4.5-nc/arch/ia64/config.in  Tue May 29 18:41:58 2001
@@ -137,6 +137,10 @@
 
 fi # !HP_SIM
 
+if [ $CONFIG_SYSCTL = y ]; then
+   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
+fi
+
 endmenu
 
 if [ $CONFIG_NET = y ]; then
diff -u --recursive linux-2.4.5/arch/mips/config.in linux-2.4.5-nc/arch/mips/config.in
--- linux-2.4.5/arch/mips/config.in

Re: [ PATCH ]: disable pcspeaker kernel: 2.4.2 - 2.4.5

[Nico Schottelius]

  less code / one int more in the kernel
  or
  more code and #ifs / one int less in the kernel

 if the #ifdefs bloat the code 4 times the size of the simple patch, then
 we obviously want 4 bytes more in the kernel.

Okay.

  And what about the code from kernel/sys.c ? The version you provided
  doesn't take care of what's the default value of pcspeaker. This would
  make it undefined, which is not really good.

 the default value is 0, that is good enough.

hmm.. I don't think so... value of 1 would be much better, because
0 normally disables the speaker.
So setting somewhere pcspeaker_enabled = 1 should be better
than having it with 0.

So in kernel/sysctl.c:

int pcspeaker_enabled = 1;

or anybody against this ?

Nico


-
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: unresolved symbols printk ?

[Nico Schottelius]

> On Mon, May 28, 2001 at 07:00:39PM +0200, Nico Schottelius wrote:
> > I am having problems with loading modules:
> > I always get the unresolved symbols message.
> > I didn't find any documentation for that, can you help me ?
>
> You did read question 8.8 from the linux-kernel mailing list FAQ?
>
>   http://www.tux.org/lkml/#s8-8

Right now, yes :)

Just a small question, what could be the reason I have a broken
Makefile ?
This seems to happen frequently, if there is a need
to name it into the lkml. I am surprised
a makefile gets screwed up ?

Nico

-
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: unresolved symbols printk ?

[Nico Schottelius]

 On Mon, May 28, 2001 at 07:00:39PM +0200, Nico Schottelius wrote:
  I am having problems with loading modules:
  I always get the unresolved symbols message.
  I didn't find any documentation for that, can you help me ?

 You did read question 8.8 from the linux-kernel mailing list FAQ?

   http://www.tux.org/lkml/#s8-8

Right now, yes :)

Just a small question, what could be the reason I have a broken
Makefile ?
This seems to happen frequently, if there is a need
to name it into the lkml. I am surprised
a makefile gets screwed up ?

Nico

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

aha152x problem

[Nico Schottelius]

Hello!

I tried to load thie aha152x modules:

modprobe aha152x io=0x140 irq=9 (which is correct)
entries in /proc/scsi are generated,
but the modprobe hangs and is unkillable.
aha152x reports scsi discs to the kernel messages,
although there are none connected to it.

I tried to use a scanner, but it it impossible
to work with the controller.

Did I miss any patches/ fixes ?


Nico

using 2.4.4

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

unresolved symbols printk ?

[Nico Schottelius]

Hello!

I am having problems with loading modules:
I always get the unresolved symbols message.
I didn't find any documentation for that, can you help me ?

What I did:

compiled 2.4.4; installed modules.
depmod -ae -F /usr/src/linux/System.map 2.4.4 runs fine,
depmod -a doesn't run fine (unresolved symbols)

modprobe any_module results in unresolved modules message.

modutils are 2.4.2.

Any ideas what I did wrong ?

Sincerly,

Nico

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

unresolved symbols printk ?

[Nico Schottelius]

Hello!

I am having problems with loading modules:
I always get the unresolved symbols message.
I didn't find any documentation for that, can you help me ?

What I did:

compiled 2.4.4; installed modules.
depmod -ae -F /usr/src/linux/System.map 2.4.4 runs fine,
depmod -a doesn't run fine (unresolved symbols)

modprobe any_module results in unresolved modules message.

modutils are 2.4.2.

Any ideas what I did wrong ?

Sincerly,

Nico

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

aha152x problem

[Nico Schottelius]

Hello!

I tried to load thie aha152x modules:

modprobe aha152x io=0x140 irq=9 (which is correct)
entries in /proc/scsi are generated,
but the modprobe hangs and is unkillable.
aha152x reports scsi discs to the kernel messages,
although there are none connected to it.

I tried to use a scanner, but it it impossible
to work with the controller.

Did I miss any patches/ fixes ?


Nico

using 2.4.4

-
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: parport problems with devfs

[Nico Schottelius]

Hmm..seems you are exactly right!

Sorry for that wrong though!

Nico

Philip Blundell wrote:

> >I attached the problem occured with parport and devfs.
> >I don't exactly know where the problem in the parport source
> >is. If someone has a patch for it, I will test it.
>
> I don't think this is a bug.  You need to load the `lp' module.
>
> p.

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

parport problems with devfs

[Nico Schottelius]

Hello!

I attached the problem occured with parport and devfs.
I don't exactly know where the problem in the parport source
is. If someone has a patch for it, I will test it.

Nico




# Loading the parport and parport_pc modules for my parallelport
flapp:/home/user/nico/gpm-1.19.3 # modprobe parport_pc

# is there an entry in /dev ?
flapp:/home/user/nico/gpm-1.19.3 # ls /dev/
. cdroms   fb  initctl  mem   ptmxroot usb
..console  fullinputmisc  pts shm  vc
.devfsd   cpu  gpmctl  kmem null  pty tty  vcc
apm_bios  discside log  port  random  urandom  zero

# What does the kernel message say ?
flapp:/home/user/nico/gpm-1.19.3 # dmesg  | tail -n 14
usb.c: registered new driver hid
mice: PS/2 mouse device common for all mice
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 7
0x378: readIntrThreshold is 7
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x10 cfgB=0x49
0x378: ECP settings irq=7 dma=1
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)


# Have a look what lp0 has been before
>From /usr/src/linux/Documentation/ :
  6 charParallel printer devices
  0 = /dev/lp0  Parallel printer on parport0
  1 = /dev/lp1  Parallel printer on parport1

# make our own device out of /dev
flapp:/ # mknod /lp0 c 6 0

# has anything happened ? No! 
flapp:/ # ls /dev/
. cdroms   fb  initctl  mem   ptmxroot usb
..console  fullinputmisc  pts shm  vc
.devfsd   cpu  gpmctl  kmem null  pty tty  vcc
apm_bios  discside log  port  random  urandom  zero

# Use the printer the easiest way :)
flapp:/ # cat /tmp/* > lp0

# And now... 
flapp:/ # ls /dev/
. cdroms   fb  initctl  mem   printers  random  urandom  zero
..console  fullinputmisc  ptmx  rootusb
.devfsd   cpu  gpmctl  kmem null  pts   shm vc
apm_bios  discside log  port  pty   tty vcc

# there is now the entry printers/0.

parport problems with devfs

[Nico Schottelius]

Hello!

I attached the problem occured with parport and devfs.
I don't exactly know where the problem in the parport source
is. If someone has a patch for it, I will test it.

Nico




# Loading the parport and parport_pc modules for my parallelport
flapp:/home/user/nico/gpm-1.19.3 # modprobe parport_pc

# is there an entry in /dev ?
flapp:/home/user/nico/gpm-1.19.3 # ls /dev/
. cdroms   fb  initctl  mem   ptmxroot usb
..console  fullinputmisc  pts shm  vc
.devfsd   cpu  gpmctl  kmem null  pty tty  vcc
apm_bios  discside log  port  random  urandom  zero

# What does the kernel message say ?
flapp:/home/user/nico/gpm-1.19.3 # dmesg  | tail -n 14
usb.c: registered new driver hid
mice: PS/2 mouse device common for all mice
0x378: FIFO is 16 bytes
0x378: writeIntrThreshold is 7
0x378: readIntrThreshold is 7
0x378: PWord is 8 bits
0x378: Interrupts are ISA-Pulses
0x378: ECP port cfgA=0x10 cfgB=0x49
0x378: ECP settings irq=7 dma=1
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)


# Have a look what lp0 has been before
From /usr/src/linux/Documentation/ :
  6 charParallel printer devices
  0 = /dev/lp0  Parallel printer on parport0
  1 = /dev/lp1  Parallel printer on parport1

# make our own device out of /dev
flapp:/ # mknod /lp0 c 6 0

# has anything happened ? No! 
flapp:/ # ls /dev/
. cdroms   fb  initctl  mem   ptmxroot usb
..console  fullinputmisc  pts shm  vc
.devfsd   cpu  gpmctl  kmem null  pty tty  vcc
apm_bios  discside log  port  random  urandom  zero

# Use the printer the easiest way :)
flapp:/ # cat /tmp/*  lp0

# And now... 
flapp:/ # ls /dev/
. cdroms   fb  initctl  mem   printers  random  urandom  zero
..console  fullinputmisc  ptmx  rootusb
.devfsd   cpu  gpmctl  kmem null  pts   shm vc
apm_bios  discside log  port  pty   tty vcc

# there is now the entry printers/0.

Re: parport problems with devfs

[Nico Schottelius]

Hmm..seems you are exactly right!

Sorry for that wrong though!

Nico

Philip Blundell wrote:

 I attached the problem occured with parport and devfs.
 I don't exactly know where the problem in the parport source
 is. If someone has a patch for it, I will test it.

 I don't think this is a bug.  You need to load the `lp' module.

 p.

-
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: Device Numbers, LILO

[Nico Schottelius]

mirabilos wrote:

> >That's not the issue.  LILO takes whatever you pass to root= and converts
> >it to a device number at /sbin/lilo time.  An idiotic practice on the
> >part of LILO, in my opinion, that ought to have been fixed a long time
> >ago.
>
> That's why you have to use append="root=blah" for devfs :)

I don't really think you have to. With 'lba32'
enabled (maybe also without that ... ) and just using lilo
normally it works with devfs.


Nico

ps: lilo.conf:

boot=/dev/discs/disc0/disc
lba32
...
image = /boot/244nospeak
  root = /dev/root
  label = nospeak
  append = "LOC=HOME"



flapp:~/bootdisk # lilo -V
LILO version 21.6



-
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 patch: disable pcspeaker (complete)

[Nico Schottelius]

Hi guys!

Some of the people of the kernel mailing list told me to
build up the disable pcspeaker support with sysctl.

It is done and works perfectly!

Will you apply the patch to kernel 2.4.5 ?
If so, can anybody or can I change the config.in files ?

Regards,

Nico


ps-1: My mail route is currently broken. please resend emails
in the next days, whether some returned!
I am working on the line problem!


p.s.: overview:

1. Changed drivers/char/vt.c (diff attached)
2. Changed arch/{i386,alpha,ppc,arm,mips}/config.in :

if [ "$CONFIG_EXPERIMENTAL" = "y" ]; then
   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
fi

(should be the last item of the 'General Setup' Menu, I don't attach
diffs
for all those different config.in files)

3. support for sysctl: changes in kernel/{sys.c,sysctl.c} and
include/linux/
   sysctl.h (diffs attached)

4. wrote text for Configure.help:

(attached)



Disables the Internal (PC) speaker
CONFIG_DISABLE_PC_SPEAKER
  Whenever you don't want your computer to be able to beep, 
  choose this option. Actually, choosing this will still not
  disable the speaker, you have to use sysctl for this:

 echo 0 > /proc/sys/kernel/pcspeaker # disable speaker
 
 echo 1 > /proc/sys/kernel/pcspeaker # enable speaker (default)

  Attention: This will not catch the beeps made directly by the
  BIOS (mostly this happens when using a notebook and pressing 
  special key codes). To disable this "BIOS-beep" enter the
  BIOS and change it there.

  If you are unsure, say N to this.




--- kernel/sysctl.c-origWed May  9 22:22:05 2001
+++ kernel/sysctl.c Wed May  9 23:44:30 2001
@@ -16,6 +16,7 @@
  *  Wendling.
  * The list_for_each() macro wasn't appropriate for the sysctl loop.
  *  Removed it and replaced it with older style, 03/23/00, Bill Wendling
+ * disable pc_speaker support, 8th of May 2001, Nico Schottelius
  */
 
 #include 
@@ -48,6 +49,10 @@
 extern int nr_queued_signals, max_queued_signals;
 extern int sysrq_enabled;
 
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+extern int pcspeaker_enabled; /* don't waste ram unless really needed */
+#endif
+
 /* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */
 static int maxolduid = 65535;
 static int minolduid;
@@ -212,6 +217,12 @@
 0444, NULL, _dointvec},
{KERN_RTSIGMAX, "rtsig-max", _queued_signals, sizeof(int),
 0644, NULL, _dointvec},
+
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+   {KERN_DISABLE_PC_SPEAKER, "pcspeaker", _enabled, sizeof(int),
+0644, NULL, _dointvec},
+#endif
+
 #ifdef CONFIG_SYSVIPC
{KERN_SHMMAX, "shmmax", _ctlmax, sizeof (size_t),
 0644, NULL, _doulongvec_minmax},
--- kernel/sys.c-orig   Wed May  9 22:33:14 2001
+++ kernel/sys.cWed May  9 23:45:26 2001
@@ -40,6 +40,14 @@
 
 int C_A_D = 1;
 
+/*
+ * whether to enable or disable the pcspeaker. default is to enable it.
+ */
+
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+int pcspeaker_enabled = 1;
+#endif 
+
 
 /*
  * Notifier list for kernel code which wants to be called
--- include/linux/sysctl.h-orig Wed May  9 22:29:22 2001
+++ include/linux/sysctl.h  Wed May  9 22:54:13 2001
@@ -118,7 +118,8 @@
KERN_SHMPATH=48,/* string: path to shm fs */
KERN_HOTPLUG=49,/* string: path to hotplug policy agent */
KERN_IEEE_EMULATION_WARNINGS=50, /* int: unimplemented ieee instructions */
-   KERN_S390_USER_DEBUG_LOGGING=51  /* int: dumps of user faults */
+   KERN_S390_USER_DEBUG_LOGGING=51,  /* int: dumps of user faults */
+   KERN_DISABLE_PC_SPEAKER=52 /* int: speaker on or off */
 };
 
 
--- drivers/char/vt.c-orig  Thu May  3 14:53:13 2001
+++ drivers/char/vt.c   Wed May  9 23:47:36 2001
@@ -7,6 +7,7 @@
  *  Dynamic keymap and string allocation - [EMAIL PROTECTED] - May 1994
  *  Restrict VT switching via ioctl() - [EMAIL PROTECTED] - Dec 1995
  *  Some code moved for less code duplication - Andi Kleen - Mar 1997
+ *  Added ability to disable the pc speaker - [EMAIL PROTECTED] - May 2001
  */
 
 #include 
@@ -40,6 +41,10 @@
 #include 
 #endif /* CONFIG_FB_COMPAT_XPMAC */
 
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+extern int pcspeaker_enabled; /* disable the pcspeaker */
+#endif
+
 char vt_dont_switch;
 extern struct tty_driver console_driver;
 
@@ -112,6 +117,12 @@
unsigned int count = 0;
unsigned long flags;
 
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+   /* is the pcspeaker enabled or disabled ? 0=disabled,1=enabled */
+   if(!pcspeaker_enabled)
+   return;
+#endif
+
if (hz > 20 && hz < 32767)
count = 1193180 / hz;

@@ -137,7 +148,7 @@
return;
 }
 
-#else
+#else /* else of machine check */
 
 void
 _kd_mksound(unsigned int hz, unsigned int ticks)

new patch: disable pcspeaker (complete)

[Nico Schottelius]

Hi guys!

Some of the people of the kernel mailing list told me to
build up the disable pcspeaker support with sysctl.

It is done and works perfectly!

Will you apply the patch to kernel 2.4.5 ?
If so, can anybody or can I change the config.in files ?

Regards,

Nico


ps-1: My mail route is currently broken. please resend emails
in the next days, whether some returned!
I am working on the line problem!


p.s.: overview:

1. Changed drivers/char/vt.c (diff attached)
2. Changed arch/{i386,alpha,ppc,arm,mips}/config.in :

if [ $CONFIG_EXPERIMENTAL = y ]; then
   bool '  Disable the PC-Speaker' CONFIG_DISABLE_PC_SPEAKER
fi

(should be the last item of the 'General Setup' Menu, I don't attach
diffs
for all those different config.in files)

3. support for sysctl: changes in kernel/{sys.c,sysctl.c} and
include/linux/
   sysctl.h (diffs attached)

4. wrote text for Configure.help:

(attached)



Disables the Internal (PC) speaker
CONFIG_DISABLE_PC_SPEAKER
  Whenever you don't want your computer to be able to beep, 
  choose this option. Actually, choosing this will still not
  disable the speaker, you have to use sysctl for this:

 echo 0  /proc/sys/kernel/pcspeaker # disable speaker
 
 echo 1  /proc/sys/kernel/pcspeaker # enable speaker (default)

  Attention: This will not catch the beeps made directly by the
  BIOS (mostly this happens when using a notebook and pressing 
  special key codes). To disable this BIOS-beep enter the
  BIOS and change it there.

  If you are unsure, say N to this.




--- kernel/sysctl.c-origWed May  9 22:22:05 2001
+++ kernel/sysctl.c Wed May  9 23:44:30 2001
@@ -16,6 +16,7 @@
  *  Wendling.
  * The list_for_each() macro wasn't appropriate for the sysctl loop.
  *  Removed it and replaced it with older style, 03/23/00, Bill Wendling
+ * disable pc_speaker support, 8th of May 2001, Nico Schottelius
  */
 
 #include linux/config.h
@@ -48,6 +49,10 @@
 extern int nr_queued_signals, max_queued_signals;
 extern int sysrq_enabled;
 
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+extern int pcspeaker_enabled; /* don't waste ram unless really needed */
+#endif
+
 /* this is needed for the proc_dointvec_minmax for [fs_]overflow UID and GID */
 static int maxolduid = 65535;
 static int minolduid;
@@ -212,6 +217,12 @@
 0444, NULL, proc_dointvec},
{KERN_RTSIGMAX, rtsig-max, max_queued_signals, sizeof(int),
 0644, NULL, proc_dointvec},
+
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+   {KERN_DISABLE_PC_SPEAKER, pcspeaker, pcspeaker_enabled, sizeof(int),
+0644, NULL, proc_dointvec},
+#endif
+
 #ifdef CONFIG_SYSVIPC
{KERN_SHMMAX, shmmax, shm_ctlmax, sizeof (size_t),
 0644, NULL, proc_doulongvec_minmax},
--- kernel/sys.c-orig   Wed May  9 22:33:14 2001
+++ kernel/sys.cWed May  9 23:45:26 2001
@@ -40,6 +40,14 @@
 
 int C_A_D = 1;
 
+/*
+ * whether to enable or disable the pcspeaker. default is to enable it.
+ */
+
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+int pcspeaker_enabled = 1;
+#endif 
+
 
 /*
  * Notifier list for kernel code which wants to be called
--- include/linux/sysctl.h-orig Wed May  9 22:29:22 2001
+++ include/linux/sysctl.h  Wed May  9 22:54:13 2001
@@ -118,7 +118,8 @@
KERN_SHMPATH=48,/* string: path to shm fs */
KERN_HOTPLUG=49,/* string: path to hotplug policy agent */
KERN_IEEE_EMULATION_WARNINGS=50, /* int: unimplemented ieee instructions */
-   KERN_S390_USER_DEBUG_LOGGING=51  /* int: dumps of user faults */
+   KERN_S390_USER_DEBUG_LOGGING=51,  /* int: dumps of user faults */
+   KERN_DISABLE_PC_SPEAKER=52 /* int: speaker on or off */
 };
 
 
--- drivers/char/vt.c-orig  Thu May  3 14:53:13 2001
+++ drivers/char/vt.c   Wed May  9 23:47:36 2001
@@ -7,6 +7,7 @@
  *  Dynamic keymap and string allocation - [EMAIL PROTECTED] - May 1994
  *  Restrict VT switching via ioctl() - [EMAIL PROTECTED] - Dec 1995
  *  Some code moved for less code duplication - Andi Kleen - Mar 1997
+ *  Added ability to disable the pc speaker - [EMAIL PROTECTED] - May 2001
  */
 
 #include linux/config.h
@@ -40,6 +41,10 @@
 #include asm/vc_ioctl.h
 #endif /* CONFIG_FB_COMPAT_XPMAC */
 
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+extern int pcspeaker_enabled; /* disable the pcspeaker */
+#endif
+
 char vt_dont_switch;
 extern struct tty_driver console_driver;
 
@@ -112,6 +117,12 @@
unsigned int count = 0;
unsigned long flags;
 
+#ifdef CONFIG_DISABLE_PC_SPEAKER
+   /* is the pcspeaker enabled or disabled ? 0=disabled,1=enabled */
+   if(!pcspeaker_enabled)
+   return;
+#endif
+
if (hz  20  hz  32767)
count = 1193180 / hz;

@@ -137,7 +148,7 @@
return;
 }
 
-#else
+#else /* else of machine check */
 
 void
 _kd_mksound(unsigned int hz, unsigned int ticks)

Re: added a new feature: disable pc speaker

[Nico Schottelius]

> >   setterm -blength 0 (text)
> >   xset b 0 (X11)
>
> Well, some buggy programs don't care about you turning off beeping in
> X.  I think gnome-terminal or such has its own checkbox for turning
> beeps on or off.

Exactly.

> I still agree that this is fixing userspace bugs in the kernel, and
> probably not desirable, even if I think I'd disable the pc speaker if
> the kernel actually asked me.  If nothing else, I figure it would make
> my kernel 0.5k or so smaller  ;)

Something about that, didn't make any comparision to a original
2.4.4 kernel.


I first thought the same Keith did, a userspace program.
This could call the same asm code used in kd_nosound,
but the problem is, the next time _kd_mksound is called,
sound is enabled again.

Can somebody give me a hint where to find documentation about
sysctl and howto use/program that ?
This is what Simon and David suggested.

But as long as I am not able to make sysctl's, I would like
to add this feature under the General setup.

What do you think ?

Nico

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