* RE: acpi-problem with samsung x10 1700
From: Brown, Len @ 2003-12-19 15:43 UTC (permalink / raw)
To: D. S., acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
AML is like C -- if there is no return statement from a routine (method)
then nothing gets returned.
Unfortunately the microsoft implementation of the AML interpreter
behaves as if there is a return statement, and so bugs in AML get
through windows validation.
For this to work on the ACPICA AML interpreter, you need to insert the
missing return statements in the AML -- we don't have a workaround for
this type of BIOS bug.
-Len
> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of D. S.
> Sent: Friday, December 19, 2003 10:10 AM
> To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: [ACPI] acpi-problem with samsung x10 1700
>
>
> hi folks,
> maybe you folks could help me out.
> i fixed the dsdt.aml so far that iasl compiles without an error.
> so far so good.
>
> now dmesg gives me the following:
>
> acpi-1121: error:method execution failed [\SB_.ADP1._STA] (Node
> c1613920), AE_AML_NO_RETURN_VALUE
> acpi-1121: error:method execution failed [\SB_.BAT1._STA] (Node
> c1613a20), AE_AML_NO_RETURN_VALUE
>
> this means, if i'm correct, that the stats for battery and ac-adapter
> can't be read.
> i am not sure where to correct this and how.
>
> so you maybe need some info on the machine/dist.
> samsung x10 xtc1700
> bios 06ye (samsung orginal shipped)
> suse 9.0 (wich is patched already for reading dsdt)
>
> help would be great!
>
> regards
> d.
>
> Some programming languages manage to absorb change, but withstand
> progress. -- Epigrams in Programming, ACM SIGPLAN Sept. 1982
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills. Sign
> up for IBM's
> Free Linux Tutorials. Learn everything from the bash shell
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
>
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
^ permalink raw reply
* udev init.d script
From: Paul Larson @ 2003-12-19 15:53 UTC (permalink / raw)
To: linux-hotplug
I was looking at the udev init.d script included with udev on a SuSE box
and noticed that it got some errors.
Actual Results:
/etc/init.d/udev: line 8: /etc/rc.d/init.d/functions: No such file or directory
/etc/init.d/udev: line 25: action: command not found
In spite of the errors, it still seemed to run correctly and create
devices, but I think it could be easily corrected to run cleanly on any
distro by simply:
1. removing line 8
2. changing the action call on line 25 to and echo
Thanks,
Paul Larson
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Announce loop-AES-v2.0d file/swap crypto package
From: Jari Ruusu @ 2003-12-19 15:57 UTC (permalink / raw)
To: linux-crypto
loop-AES changes since previous release:
- v2.0c SMP race fix created new race with small security hole on 2.2 and
2.0 kernels when loop is in multi-key mode. That security hole is now
fixed. No change at all for 2.4 and later kernels because they were not
affected.
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.0d.tar.bz2
md5sum efd11783ddf5f6cbd3f524f5e42b46dd
http://loop-aes.sourceforge.net/loop-AES/loop-AES-v2.0d.tar.bz2.sign
Additional ciphers package changes since previous release:
- v2.0c SMP race fix created new race with small security hole on 2.2 and
2.0 kernels when loop is in multi-key mode. That security hole is now
fixed. No change at all for 2.4 and later kernels because they were not
affected.
bzip2 compressed tarball is here:
http://loop-aes.sourceforge.net/ciphers/ciphers-v2.0d.tar.bz2
md5sum 98c717e5e0c2daceacc228a17847cbcf
http://loop-aes.sourceforge.net/ciphers/ciphers-v2.0d.tar.bz2.sign
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
^ permalink raw reply
* 2.6.0, advanced routing and masquerade
From: linuxmail @ 2003-12-19 15:58 UTC (permalink / raw)
To: netfilter-devel
Hi,
Sorry for posting this to development - I did try the user list and didn't get a reply. From further experimentation (and implementing stable 2.6.0 for good measure) it looks like a bug.
I've been running my current network configuration for over a year on the 2.4.xx kernels without any issues. I'm now using using 2.6.0 and without any configuration changes I'm having issues with advanced routing combined with masquerading.
To reproduce the problem here is a simplified breakdown of my configuration.
eth0 : Internal Network
eth1 : Cable Modem
eth2 : ADSL modem
The default route for all traffic is the ADSL modem but certain protocols/machines route across the cable modem. The cable modem only has a single publish IP (bound to eth1) and, therefore, it is necessary to NAT.
So....
$ iptables -A POSTROUTING -s 192.168.0.10 -d ! 192.168.0.0/24 -o eth1 -t nat -j MASQUERADE
$ ip rule add from 192.168.0.10 table cm prio 1000
$ ip route add default via 1.2.3.254 dev eth1 table cm
----
$ ip rule list
0: from all lookup local
1000: from 192.168.0.10 lookup cm
32766: from all lookup main
32767: from all lookup default
$ ip route show table cm
default via 1.2.3.254 dev eth1
$ iptables -t nat -L -n
iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.10 !192.168.0.0/24
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
------
This works fine on the 2.4.22 kernel but in 2.6 traffic destined for the cable modem generates a "MASQUERADE: Route sent us somewhere else." error.
However, replacing the MASQUERADE config with SNAT (which I'd rather not do in production given the IP is dynamic on that gateway) -
iptables -A POSTROUTING -s 192.168.0.1 -d ! 192.168.0.0/24 -t nat -o eth1 -j SNAT --to-source 1.2.3.4
- Works fine!!!
I know this bug cropped up in 2.4.23 and a fix was issued. Could someone confirm there is a similar issue in 2.6.0?
Sorry if I've missed the point completely.
Steve.
-----------------------------------------
Email provided by http://www.ntlhome.com/
^ permalink raw reply
* Re: JFFS patch
From: Allen Curtis @ 2003-12-19 15:57 UTC (permalink / raw)
To: David Woodhouse; +Cc: Infradead Org, jffs-dev
In-Reply-To: <1071785993.3550.8.camel@lapdancer.baythorne.internal>
>
> Dud it? Are you still interested in maintaining JFFS 1? It's getting on
> for time for it to be dropped from 2.6 if nobody wants to look after
> it.
I am sorry. I have been busy teaching an embedded systems course. This
is now completed. Please send me the current issues and will address
them over break.
Thanks
^ permalink raw reply
* Re: [patch] ide.c as a module
From: Krzysztof Halasa @ 2003-12-18 0:29 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: linux-kernel
In-Reply-To: <200312121837.31121.bzolnier@elka.pw.edu.pl>
BTW: modular IDE in 2.4.23 is still problematic - you can't unload the
chipset driver (piix.o or something like) which in turn references the
core IDE module.
Is anyone working on it? I could probably fix it but I don't want to
duplicate the efforts.
--
Krzysztof Halasa, B*FH
^ permalink raw reply
* RE: HELP! Compaq TC1000 ACPI - Disable IRQ #9
From: Brown, Len @ 2003-12-19 16:02 UTC (permalink / raw)
To: Carlos Noguera, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
Has any other distribution or kernel version successfully run on this
box?
If it fails with and without acpi=off, then ACPI can't be causing the
problem (unless acpi=off is broken). Though it it conceivable that ACPI
can be part of the solution.
Do you have a windows disk for it? Might be helpful to use it to see if
the hardware is working and examine the IRQ assignments.
Tough to debug this one if you can't get in via console or network.
I don't suppose there is a serial port on this box you can use
For a serial console to capture the dmesg and /proc/interrupts?
I assume that this is a PIC-mode box and it doesn't have an IOAPIC?
Sometimes "nolapic" is needed to make such boxes work (stab in dark)
Or you can build the kernel w/o LOCAL APIC support.
IRQs get disabled if the kernel gets a bunch of interrupts on an IRQ but
doesn't find an interrupt handler to handle them. This can be caused by
just about any mis-configuration, including reversing the polarity of
the interrupt, or assigning the device to an IRQ it isn't physically
attched to. You might be able to get the system up for further
debugging if disable the disabling of the IRQ and just weather the
interrupt storm so that you can get some packets through your ethernet.
> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
> Carlos Noguera
> Sent: Thursday, December 18, 2003 6:07 PM
> To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: [ACPI] HELP! Compaq TC1000 ACPI - Disable IRQ #9
>
>
> I own a Compaq TC1000 Tablet PC and have been trying to get Gentoo
> running on it, using the love-sources 2.6.0-test11-love 4 + ACPI patch
> set (from
> http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patche
s/test/2.6.0-test11/ ).
No matter what I do, nor what kernel options I throw at it (including
acpi=off), if the keyboard/mouse combo don't sense activity (i.e.
keypress) I get a message of "Disable IRQ #9" during bootup. This
usually occurs around the enabling hotplug stage.
The worse part is that this IRQ is shared among my OHCI controller AND
my eth0, so if it's disabled I have no way to log into the machine.
I've looked and looked all over the mailing lists and applied all sorts
of pathes, to no avail. If I don't press keys during bootup, I get no
keyboard or ethernet. :-/
Thanks in advance for your help...
[C]arlos
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for
IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
^ permalink raw reply
* Re: ep8260 board linux port
From: Allen Curtis @ 2003-12-19 16:05 UTC (permalink / raw)
To: Kiran Mandava; +Cc: linuxppc-embedded
In-Reply-To: <DBF73ACB70D3D711A358000BDBACF5CE09D23B@SSMAIL1>
> I am trying to port linux 2.4.22 onto ep8260 board. (256 MB RAM on
> 6xx
> bus/ 32 MB Flash) using tools and source code from denx webisite.
> I was able to port u-boot and trying to boot linux now.
> i couldn't find any specific files to this board in the platform
> directory
> although est8260.h file has the basic bd structure. the problem i am
> facing
> is the processor loops in serial_console_write/ timer interrupt
> handler. i
> made sure that i am passing the baudrate proeprly by looking at the bd
> structure while passing teh control to start_kernel function.
>
How are you creating your boot image. If you are following the u-boot
directions then you don't need any board specific support in the
kernel. If you are trying to boot zImage, then you have more work to
do.
> My console does display everything properly running u-boot but once
> the
> control goes to linux don't see anything on the console.
>
Did you happen to customize the BAUD rate information for u-boot or
Linux? The u-boot default is 115K, Linux default is 9600.
Another thing that I have run into is the clock divider configuration
by u-boot. Try changing your minicom baud rate up or down by 4X and see
if you see anything then.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* RE: acpi-20031203-2.6.0.diff brokes the battery status readings with 2.6.0 in DELL Inspiron 8500
From: Brown, Len @ 2003-12-19 16:11 UTC (permalink / raw)
To: Pere Castañer, acpi-devel
dmesg from before and after would help, plus the info under /proc/acpi/battery.
Thanks,
-Len
> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of
> Pere Castañer
> Sent: Thursday, December 18, 2003 7:00 PM
> To: acpi-devel
> Subject: [ACPI] acpi-20031203-2.6.0.diff brokes the battery
> status readings with 2.6.0 in DELL Inspiron 8500
>
>
> I've just aplyied last patch into 2.6.0 stable release and it
> brokes the battery monitor from acpi in
> /proc/acpi/battery/BAT0/status...because of this
> gnome-battery applet don't shows any information.
>
> Do you need more information?
>
> PS:with acpi included on 2.6.0 all works fine.
>
>
> --
> "Soy una piedra, no muevo ni un músculo,lentamente me pongo nieve
> en la boca para que no vea mi aliento , me tomo mi tiempo,
> dejo que se acerque, sólo tengo una bala, apunto a sus ojos, muy
> suavemente mi dedo presiona el gatillo,mi pulso no tiembla, no
> tengo miedo: ahora ya soy mayor"
> Enemy at gates
> ------
> Pere Castañer Sardà - http://xarz.no-ip.org
> GnuPG Public key available - http://xarz.no-ip.org/keys.html
> Computer Science Student on UOC - http://www.uoc.edu
> Linux Registered User #232073
> Debian/GNU User - http://www.debian.org
> ---------------------
>
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click
^ permalink raw reply
* Re: [Vserver] Re: [parisc-linux] syscall number for vserver
From: Grant Grundler @ 2003-12-19 16:11 UTC (permalink / raw)
To: Herbert Poetzl; +Cc: vserver, parisc-linux
In-Reply-To: <20031219032455.GB8847@MAIL.13thfloor.at>
On Fri, Dec 19, 2003 at 04:24:56AM +0100, Herbert Poetzl wrote:
...
> sure not, but gettimeofday for example, will
> return the current time, and this usually does
> not need an architecture specific interface
glibc
> (for sure it will require an arch specific
> implementation ;)
possible a different syscall.
Sounds like we agree.
...
> > to test with and enabling the kernel config options, right?
>
> well, yeah, that is what I did to add the parisc(64)
> vserver support, except that it doesn't have
> a kernel config option yet ;)
That should be part of the patch to enable vserver.
> > BTW, I visited http://www.linux-vserver.org/ and didn't feel
> > I understood why it's more useful than say, user mode linux
> > (another form of virtualization) or vPARs.
>
> hmm, for UML you'll need a kernel for each vps,
> which eats up a lot of resources, where vserver
> even allow you to share the files between vps
Has anyone bothered to quantify how much resource?
In general, systems are memory starved, so this sounds
like a good thing.
> regarding vPARs, I didn't know that they work
> for Linux yet, can you give some hints on that?
Several arches are capable of running the OS via a "monitor"
that abstracts the HW (even emulating IO devices depending on
the implementation). Thus allows several OS instances to run
at the same time. It's not too different from UML except that
the monitor is "lighter weight" than a Linux kernel host and
can run different OSs (ie not just linux) at the same time.
Search for "vPARs" on www.hp.com if you want more details
on HPUX vPARs support.
grant
^ permalink raw reply
* Re: [Vserver] Re: [parisc-linux] syscall number for vserver
From: Grant Grundler @ 2003-12-19 16:11 UTC (permalink / raw)
To: Herbert Poetzl; +Cc: vserver, parisc-linux
In-Reply-To: <20031219032455.GB8847@MAIL.13thfloor.at>
On Fri, Dec 19, 2003 at 04:24:56AM +0100, Herbert Poetzl wrote:
...
> sure not, but gettimeofday for example, will
> return the current time, and this usually does
> not need an architecture specific interface
glibc
> (for sure it will require an arch specific
> implementation ;)
possible a different syscall.
Sounds like we agree.
...
> > to test with and enabling the kernel config options, right?
>
> well, yeah, that is what I did to add the parisc(64)
> vserver support, except that it doesn't have
> a kernel config option yet ;)
That should be part of the patch to enable vserver.
> > BTW, I visited http://www.linux-vserver.org/ and didn't feel
> > I understood why it's more useful than say, user mode linux
> > (another form of virtualization) or vPARs.
>
> hmm, for UML you'll need a kernel for each vps,
> which eats up a lot of resources, where vserver
> even allow you to share the files between vps
Has anyone bothered to quantify how much resource?
In general, systems are memory starved, so this sounds
like a good thing.
> regarding vPARs, I didn't know that they work
> for Linux yet, can you give some hints on that?
Several arches are capable of running the OS via a "monitor"
that abstracts the HW (even emulating IO devices depending on
the implementation). Thus allows several OS instances to run
at the same time. It's not too different from UML except that
the monitor is "lighter weight" than a Linux kernel host and
can run different OSs (ie not just linux) at the same time.
Search for "vPARs" on www.hp.com if you want more details
on HPUX vPARs support.
grant
^ permalink raw reply
* [uml-devel] Re: Bug#224502: FATAL: cannot determine library version
From: Matt Zimmerman @ 2003-12-19 16:11 UTC (permalink / raw)
To: user-mode-linux-devel; +Cc: Bill Allombert, 224502-forwarded
In-Reply-To: <20031219143655.GA7944@pari.math.u-bordeaux.fr>
On Fri, Dec 19, 2003 at 03:36:55PM +0100, Bill Allombert wrote:
> I have upgraded from 2.4.22-5um-1 to 2.4.22-7um-1 and now
> user-mode-linux fail to start with
>
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> VFS: Mounted root (ext2 filesystem) readonly.
> FATAL: cannot determine library version
Strange. I think this error message comes from ld.so.
> Kernel panic: Attempted to kill init!
>
> The host kernel is 2.4.22+Debian patch+SKAS Debian patch
> The machine is a bi-processor athlon.
> The command line is
> linux ubd0=uml root=/dev/ubd0
>
> 2.4.22-5um-1 work fine.
>
> On another host without the skas patch, rootstrap lead to
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
> VFS: Mounted root (hostfs filesystem) readonly.
> Mounted devfs on /dev
>
> and then it hang.
2.4.22-7um-1 works fine for me in skas mode. There is a problem in tt mode
which has already been reported (#224431).
--
- mdz
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
^ permalink raw reply
* Re: cpu won't stay in powersave mode
From: Dominik Brodowski @ 2003-12-19 16:15 UTC (permalink / raw)
To: Tom Bruno; +Cc: cpufreq
In-Reply-To: <1071501484.21334.1.camel@localhost>
[-- Attachment #1.1: Type: text/plain, Size: 1602 bytes --]
On Mon, Dec 15, 2003 at 03:18:04PM +0000, Tom Bruno wrote:
> Sorry, accendtly hit reply instead of send to list.
>
> On Mon, 2003-12-15 at 14:14, Thomas Renninger wrote:
> > Tom Bruno wrote:
> >
> > >Like i said above if I change it via hand using echo, /proc/cpuinfo
> is
> > >correct, and the cputest reports the correct speed constantly.
> > >
> > >performance mode: 2.4ghz
> > >powersave mode: 1.2ghz
> > >Intel P4-M 2.4ghz
> > >Dell Inspiron 8500 - Bios A05
> > >kernel-2.6.0-test11
> > >
> > >
> > /proc/cpu_info didn't work for me, too.
> > However it seems to work now(after I changed the governors to be
> > compiled as modules(or the way around?)).
> >
> I've now tried both as modules, and compiled in, /proc/cpuinfo works
> niether report correctly.
>
> > If you want to detemine the current real speed of your machine use the
> > procspeed prog I posted some days ago(04.12, 09.12).
>
> yes, that is the program i spoke of. However, like i said, when
> /proc/cpuinfo is reporting wrong, my system works it's way back to full
> speed even though powersave is in the /sys scaling_governor.
>
> It will report the changed speed (clockdown to 1.2ghz) for about 10
> seconds, and then will start to report again at 2.4ghz even though the
> setting haddn't changed.
I think the BIOS is meddling with the speedstep setting [this is more
common for older systems, but obviously some vendors still think it's a good
idea] . If it were cpufreq, the value in /proc/cpuinfo would be updated as
well.
Do you run an ACPI-enabled kernel?
Dominik
[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
Cpufreq mailing list
Cpufreq@www.linux.org.uk
http://www.linux.org.uk/mailman/listinfo/cpufreq
^ permalink raw reply
* Re: [PATCH] Module Alias back compat code
From: OGAWA Hirofumi @ 2003-12-19 16:16 UTC (permalink / raw)
To: Rusty Russell; +Cc: akpm, linux-kernel
In-Reply-To: <20031219031034.A38502C06C@lists.samba.org>
Rusty Russell <rusty@rustcorp.com.au> writes:
> The provides backwards compat for old char and block aliases.
>
> MODULE_ALIAS_BLOCK() and MODULE_ALIAS_CHAR() define aliases of form
> "XXX-<major>-<minor>", so we should probe for modules using this
> form. Unfortunately in 2.4, block aliases were "XXX-<major>" and
> char aliases were of both forms.
>
> Ideally, all modules would now be using MODULE_ALIAS() macros to
> define their aliases, and the old configuration files wouldn't
> matter as much. Unfortunately, this hasn't happened, so we make
> request_module() return the exit status of modprobe, and then
> do fallback when probing for char and block devices.
Umm.. Although I may be mis-understanding this problem, is the following
scripts the not enough?
This does
block-major-1 -> block-major-1-*
--- generate-modprobe.conf.orig 2003-08-12 05:03:59.000000000 +0900
+++ generate-modprobe.conf 2003-12-20 00:31:17.000000000 +0900
@@ -59,8 +59,9 @@
parse_alias()
{
PA_ALIAS=`resolve_alias $1 $3`
+ NAME=`echo $2|sed -e 's/\(block\|char\)-major-\([0-9]\+\)$/\1-major-\2-*/'`
- echo "alias $2 $PA_ALIAS"
+ echo "alias $NAME $PA_ALIAS"
}
# Parse options: args modulename aliasto.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* [PATCH] Remove use of nameidata by selinux_inode_permission
From: Stephen Smalley @ 2003-12-19 16:18 UTC (permalink / raw)
To: Andrew Morton, James Morris, lkml
This patch against 2.6.0 removes the use of nameidata by
selinux_inode_permission, as this appears to be unsafe in certain cases
(e.g. path_walk call from rpc_lookup_parent), leading to an Oops if
d_path is subsequently called by avc_audit on the (mnt,dentry) pair to
generate a pathname for an audit message. The change does not affect
the ability of SELinux to perform its permission check (which only
requires the inode), only the set of information that is available for
audit messages. We'll investigate better approaches for the SELinux
audit generation in the future. Please apply, or let me know if you
would like me to resubmit later.
security/selinux/hooks.c | 4 ----
1 files changed, 4 deletions(-)
--- linux-2.6.0/security/selinux/hooks.c 2003-12-17 21:59:41.000000000 -0500
+++ linux-2.6.0-respin/security/selinux/hooks.c 2003-12-19 10:42:20.000000000 -0500
@@ -1738,10 +1738,6 @@
return 0;
}
- if (nd && nd->dentry)
- return dentry_has_perm(current, nd->mnt, nd->dentry,
- file_mask_to_av(inode->i_mode, mask));
-
return inode_has_perm(current, inode,
file_mask_to_av(inode->i_mode, mask), NULL, NULL);
}
--
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency
^ permalink raw reply
* Problem with mtd-snapshot-20031211.tar
From: Thomas Pang @ 2003-12-19 16:16 UTC (permalink / raw)
To: 'J B'; +Cc: linux-mtd
In-Reply-To: <Law11-F49ynA6xSm1A00005337c@hotmail.com>
I am using AMD NOR+SRAM flash in MCP (multi-chip packages) with CFI
support.
Thanks.
Thomas
-----Original Message-----
>I download the boot image into my target system and successfully boot
up
>the board. I also download the file systems, one is CRAMFS, another
one
>is JFFS2.
What kind of flash chips does your board have? AMD, Intel, etc and NOR
or
NAND?
>
>I am using the latest mkfs.jffs2 to create my JFFS2 file system as
shown
>below:
>
>mkfs.jffs2 -p -e 0x10000 -c 12 -b -r rootfs -o jffsImage
>
>Problem 1 (Fail to mount JFFS2 file system)
>===========================================
>
>I seem to be able to mount the JFFS2 file system but when I access the
>JFFS2 file system, the system complains "Chip not ready after erase
>suspended: status = 0x1985". Any idea?
0x1985 is the magic number on a jffs2 filesystem. Looks like the chip
driver is trying to read the status register of the chips and its in
read
array mode, not read status.
># ls
>Chip not ready after erase suspended: status = 0x1985
>error -5 reading node at 0x001901f8 in get_inode_nodes()
>jffs2_get_inode_nodes() for ino 2 returned -5
>ls: ./bin: Input/output error
see comment about magic number above. JFFS2 is probably erasing any
extra
eraseblocks you have so it can use them and the erase suspend is
failing
when the ls command is done.
>Problem 2 (Writing to JFFS2 file system still slow)
<snip>
> rm myfile
> cp bin/myfile .
> Chip not ready after erase suspended: status = 0xffff
> Chip not ready after erase suspended: status = 0xffff
looks like the same problem. 0xffff is what erased flash blocks look
like.
So two questions are, what kind of flash chips do you have, and what mtd
chip driver are you using?
j
_________________________________________________________________
Enjoy the holiday season with great tips from MSN.
http://special.msn.com/network/happyholidays.armx
^ permalink raw reply
* Re: usb storage traces
From: Pat LaVarre @ 2003-12-19 16:21 UTC (permalink / raw)
To: Alan Stern
Cc: linux-scsi, usb-storage, Matthew Dharm, David Brownell,
Alex Sanks, Julian Back
In-Reply-To: <Pine.LNX.4.44L0.0312190945170.805-100000@ida.rowland.org>
> The URL for my traces is:
> http://www.win.tue.nl/~aeb/linux/usb/traces/winme/
Thank you!
> ... doesn't show up in the default directory listing ...
> http://www.win.tue.nl/~aeb/linux/usb/traces/winme/README.txt
To the wish list for RMB please add:
Traces of disk absent (not just traces of disk present).
> One interesting thing about Windows ME
> stands out from reading the files:
> It seems to think the right way to recover
> from a "device was reset" response is to reset the device twice!
On my second reading I guess we here mean to be speaking of sk asc x 6
29. I agree, silly to respond to a notification of reset received by
sending another reset.
On my first reading I wrongly guessed we here were speaking of some
other kind of trouble, to which I answered:
Why should this surprise us?
Reset, like any i/o operation, may fail. Hosts that live by
"be liberal in what you accept" time out and retry resets, yes. In
particular, by trying twice we more liberally tolerate those apparently
generic devices that in fact occasionally choose to scramble the status
phase data toggle at the end of a class-specific reset. Naive hosts see
that as indefinite NAK.
Pat LaVarre
http://plavarre.blog-city.com/index.cfm?d=19&m=12&y=2003
^ permalink raw reply
* Re: [patch] ide.c as a module
From: Bartlomiej Zolnierkiewicz @ 2003-12-19 16:26 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: linux-kernel
In-Reply-To: <m3u13zynm8.fsf@defiant.pm.waw.pl>
On Thursday 18 of December 2003 01:29, Krzysztof Halasa wrote:
> BTW: modular IDE in 2.4.23 is still problematic - you can't unload the
> chipset driver (piix.o or something like) which in turn references the
> core IDE module.
It is probably too much work to fix it (properly) in 2.4.x and 2.6.x...
Please note that there is no refcounting in IDE drivers,
there is no host object type, also table of IDE ports (ide_hwifs[]) is static.
I hope 2.7 will obsolete drivers/ide...
--bart
^ permalink raw reply
* Re: Would setting the CONFIG_RTC option break the powerpc kernel on your machine ?
From: Tom Rini @ 2003-12-19 16:28 UTC (permalink / raw)
To: Sven Luther
Cc: Benjamin Herrenschmidt, Lee Braiden, debian-powerpc, linuxppc-dev
In-Reply-To: <20031219114050.GA5650@iliana>
On Fri, Dec 19, 2003 at 12:40:50PM +0100, Sven Luther wrote:
> On Wed, Dec 17, 2003 at 10:06:20AM -0700, Tom Rini wrote:
> >
> > On Wed, Dec 17, 2003 at 05:56:08PM +0100, Sven Luther wrote:
> > >
> > > On Wed, Dec 17, 2003 at 09:47:40AM -0700, Tom Rini wrote:
> > > > 4) Use CONFIG_GEN_RTC and be happy. What _might_ be happening right now
> > > > is that chrp_get_rtc_time is 'funky' and not quite right for anything
> > > > other than an IBM OpenFirmeware'd CHRP box. What I would suggest is
> > > > looking at include/asm-generic/rtc.h in 2.6 and moving much of that code
> > > > into 'chrp_get_rtc_time' and 'chrp_set_rtc_time'.
> > >
> > > Ok, thanks, i will look into it.
> > >
> > > But then, remember, this is for the debian powerpc kernel, and has to be
> > > 2.4.x still for now.
> >
> > Yes. The code in <asm-generic/rtc.h> is taken right from
> > drivers/char/rtc.c. It just didn't get sent to 2.4 for some reason.
>
> Ok, found the code, altough drivers/char/rtc.c doesn't seem to have a
> set_rtc_time function.
Nope, that's why I suggested 2.6's <asm-generic/rtc.h> :)
> BTW, what exactly should i do in 'chrp_get_rtc_time' and
> 'chrp_set_rtc_time' ? Just replace the existing code, or make a new
> function, and set it depending on machine type who needs it in
> chrp_setup.c ? I already do that for the pegasos irq stuff. I just would
> have to set ppc_md.set_rtc_time accordyingly.
My preferance would be to replace, and then see if it breaks some other
chrp machines (it really shouldn't).
Something that just dawned on me again (sorry) is that I've really really
intended to try and kill both prep_time.c and chrp_time.c (since both of
those machine subtypes have PC-style RTC chips) and make them use
todc_time.c (see arch/ppc/kernel/todc_time.c). I've got patches to do
half of this, against 2.6 (which was a trivial forward port of older
2.4-based patches I had, there is nothing 2.6-specific about these
patches). You would want to look at:
006-redo_inb_inw_inl_outb_outw_outl.patch
007-make_out_8_and_friends_synchronous.patch
008-todc_warning.patch
009-prep_time_death-GNU.patch
from http://stop.crashing.org:16080/~trini/
--
Tom Rini
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 2.6-test11 framebuffer Matrox
From: nick black @ 2003-12-19 16:28 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200312190314.13138.schwientek@web.de>
In article <200312190314.13138.schwientek@web.de>, Steffen Schwientek wrote:
> My Matrox-framebuffer is not working properly. Build direct into the
> kernel, the monitor will be black with some stripes at startup, just the
> reset button works.
> Build as a modules, the same happens if I load the module.
I've managed to get my AGP G400 working in the following setups under
2.6.0 since -test7:
with Petr's patch, reverting to 2.4 interfaces:
video=matroxfb:vesa:0x1bb gives me a great fbcon. I can either use
X's fbdev driver at the same resolution, or the mga driver at any
resolution, with no problems.
without Petr's patch:
video=matroxfb:vesa:0x1bb gives me a great fbcon. I can only use
X's fbdev driver at the same resolution; the mga driver at any
resolution causes massive console corruption upon switching from X to
console and causing any screen changes. Also, I get a large white
block underneath the logo on boot.
--
nick black <dank@reflexsecurity.com>
"np: nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo
^ permalink raw reply
* Re: 2.6-test11 framebuffer Matrox
From: nick black @ 2003-12-19 16:29 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <3FE2BB05.1000107@convergence.de>
In article <3FE2BB05.1000107@convergence.de>, Michael Hunold wrote:
> Hmm, I just tested with the 2.6.0 release and my both cards are working
> properly now. The only thing is a huge white box around the penguin logo.
As I said, this happens to me without Petr's patch, and goes away with
it. Can you check out my earlier post in this thread, and analyze your
X+fbcon interaction with reagrds to fbdev vs. mga driver, and Petr's
patch?
--
nick black <dank@reflexsecurity.com>
"np: nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo
^ permalink raw reply
* Re: [linux-lvm] Ext3 -> ReiserFS on '/' convertion prob
From: Madison Kelly @ 2003-12-19 16:31 UTC (permalink / raw)
To: linux-lvm
In-Reply-To: <3FE36BAF.7030406@stercomm.com>
I will investigate that further... May I make one more comment that may
help me solve this? Quick note, since the last post I wiped the test
server and re-installed, just in case I had foobar'ed something along
the way.
I have made a backup of '/' (from '/dev/vg0/root') to the backup drive
(/dev/sdd1) and edited '/etc/fstab', '/etc/mtab' and deleted
'/etc/blkid.tab' (which, if I understand is just a cache). I did this on
both the '/' (/dev/vg0/root and /dev/sdd1) while under the Linux Rescue
disk (Fedora Core 1 install in 'linux rescue') and finally I updated
'/boot/grub/grub.conf' on both partitions as well to contain entries
pointing '/' to '/dev/sdd1'. When I reboot (before converting the LVM LV
to ReiserFS) and choose to boot into '/dev/sdd1' as root it -seems- to
work. When I type:
# df
It shows '/' to be '/dev/sdd'. Now to verify this I did:
# cd /
# touch test.txt
# mkdir vg0
# mount /dev/vg0/root /vg0
I then checked to see if the 'test.txt' file was there, and it was. How
the heck can the original settings for '/dev/vg0/root' be -SO-
persistent that even 'df' thinks that the wrong partition is mounted?!?
Where are these settings stored?
Side note: When I boot again off the rescue disk and run the same test
(with '/dev/sdd1' mounted as '/') then it is fine, there '/' really is
'/dev/sdd1'...)
Anyway, I am off to try converting again now that I know to try passing
"init=reiserfs" in grub (will it work though?... Off to see!)
Thank you for being so helpful and patient while I pound my head through
this!
Madison
Chris Cox wrote:
> Madison Kelly wrote:
>
>> I am so sorry for asking but how would I check?
>>
>
> I'm a SUSE user myself. It's mkinitrd script
> makes it pretty easy to add modules to your
> initrd. I'd check that lvm_mkinitrd script
> of yours... you may have to tweak it.
> In fact, SUSE's script detects (tries anyway) if
> your root filesystem is LVM's and automatically
> adds in the lvm_mod if it wasn't specified.
>
> There's probably a way to find out easily if
> it's there already.. just not sure off the top of my head.
^ permalink raw reply
* [2.6.0 cpufreq] longhaul trouble
From: Jurgen Kramer @ 2003-12-19 16:32 UTC (permalink / raw)
To: linux-kernel
When I insert the longhaul cpufreq module on my VIA EPIA 800 the system
completely freezes. It does not give any oops or other helpful error
message.
Through ACPI I can only use the throttling function, I can not switch
between 400 and 800 MHz.
Jurgen
output of /proc/cpu
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 7
model name : VIA Ezra
stepping : 8
cpu MHz : 800.048
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow
bogomips : 1595.80
^ permalink raw reply
* Re: Mount Rainier in 2.6
From: Jens Axboe @ 2003-12-19 16:35 UTC (permalink / raw)
To: linux-kernel; +Cc: jaharkes
In-Reply-To: <20031218225236.GA27102@delft.aura.cs.cmu.edu>
On Thu, Dec 18 2003, Jan Harkes wrote:
> On Thu, Dec 18, 2003 at 08:34:14PM +0100, Jens Axboe wrote:
> > On Thu, Dec 18 2003, Milos Prudek wrote:
> > Rats, I forgot to test sr. You probably don't have a SCSI mt rainier
> > drive (I doubt one was ever made), so just disable SCSI CD-ROM support.
>
> Actually, external USB enclosures show up as SCSI even when they
> internally have a regular IDE/ATAPI drive. Your original patches (early
> 2.5?) did work nicely with an external USB2.0 writer.
Oh you are right - the incremental patch should fix sr, so it ought to
work.
--
Jens Axboe
^ permalink raw reply
* Re: cciss update for 2.4.24-pre1, #3
From: Marcelo Tosatti @ 2003-12-19 16:22 UTC (permalink / raw)
To: mikem; +Cc: axboe, marcelo.tosatti, linux-kernel, mike.miller, scott.benesh
In-Reply-To: <Pine.LNX.4.58.0312170909380.30620@beardog.cca.cpqcorp.net>
On Wed, 17 Dec 2003 mikem@beardog.cca.cpqcorp.net wrote:
> Sorry I forgot to send this fix in with the 2 patches I submitted
> yesterday. We found a bug in the ASIC used on the 64xx Smart Array
> controllers. When prefetching from host memory we grab an extra 750 or
> so bytes of data. If this occurs on a memory boundary the machine will crash.
> This is primarily an issue on IPF and Alpha systems although it could happen
> on other platforms. Proliant systems are not affected by this bug because
> memory is contiguous and the top 4k of memory is masked off by the system
> firmware. The solution to the problem is to disable SCSI prefetch in the
> controller firmware. This results in a performance hit on x86 during RAID1
> operations. This patch turns on prefetch for x86 based systems only.
> Please consider this patch for inclusion in the 2.4.24 kernel.
> This patch should be applied after the 2 I submitted yesterday. It will
> patch into a fresh tree with offsets.
The other two patches have been included.
Has the prefetching been tested for long? Which kernels have it enabled?
What about 2.6?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.