* [U-Boot-Users] NFS Server problem
From: sudhakar rajashekhara @ 2004-01-27 14:06 UTC (permalink / raw)
To: u-boot
Hi,
I have sucessfully ported U-boot on MPC8280 board. I
am using FCC2 for ethernet. I am able to boot Linux
correctly. But sometimes I face some strange problems
such as the board suddenly stops responding to
commands saying:
=======================================
nfs: server not responding, still trying
=======================================
Sometimes, the board continues after printing,
=======================================
nfs: server OK
=======================================
but sometimes the board just hangs. Earlier I have
ported U-boot to sbc8260 board and there I was using
SCC for ethernet. I never faced such problems there.
Is this problem (on MPC8280) because of any problems
in FCC ethernet configuration?
thanks in advance,
regards,
Sudhakar.
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
^ permalink raw reply
* [PATCH] XFS: remove warning in xfs_log_recover, 2.6.2-rc2
From: Michael Veeck @ 2004-01-27 14:09 UTC (permalink / raw)
To: owner-xfs; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 518 bytes --]
Compiling the 2.6.2-rc2 kernel on my machine with allyesconfig and gcc
3.3.1 triggers the following warning:
CC fs/xfs/xfs_log_recover.o
fs/xfs/xfs_log_recover.c: In function `xlog_recover_reorder_trans':
fs/xfs/xfs_log_recover.c:1534: warning: `flags' might be used
uninitialized in this function
I've added an "= 0" to the appropiate line which lets it cleanly compile
now. Attached patch fixes the warning and is against 2.6.2-rc2. Apply
with patch -p1 < patch-XFSwarning.
Best regards
Michael Veeck
[-- Attachment #2: patch-XFSwarning --]
[-- Type: text/plain, Size: 453 bytes --]
diff -Naur a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c
--- old/fs/xfs/xfs_log_recover.c 2004-01-27 14:28:03.000000000 +0100
+++ new/fs/xfs/xfs_log_recover.c 2004-01-27 14:02:25.000000000 +0100
@@ -1531,7 +1531,7 @@
xlog_recover_item_t *first_item, *itemq, *itemq_next;
xfs_buf_log_format_t *buf_f;
xfs_buf_log_format_v1_t *obuf_f;
- ushort flags;
+ ushort flags = 0;
first_item = itemq = trans->r_itemq;
trans->r_itemq = NULL;
[-- Attachment #3: README --]
[-- Type: text/plain, Size: 106 bytes --]
[PATCH] xfs has uninitialized flags-variable in xfs_log_recover. init it to 0. from michael.veeck@gmx.net
^ permalink raw reply
* Re: [Bluez-devel] Device specific pins
From: Marcel Holtmann @ 2004-01-27 14:10 UTC (permalink / raw)
To: Eugene Crosser; +Cc: Dave Henriksen, BlueZ Mailing List
In-Reply-To: <1075187139.9727.29.camel@pccross.average.org>
Hi Eugene,
> Do you think it might be right to leave "low level" PIN management as it
> is now, via an executable helper? It is very much the same way as
> kernel "hotplug" works. So it can stay the same even if hcid eventually
> becomes a kernel thread.
>
> The "real" PIN management, with the database, GUI prompt boxes etc.
> could be isolated from the BT stack, helper executable being the only
> interface.
>
> E.g., a Gnome or KDE applet could listen on a unix domain socket. The
> helper, when invoked, would try to talk over this socket, and if the
> latter is not present or nobody listens on it, default to preexisting
> database. This way, both fancy GUI dialogues and unattended operation
> could be implemented rather easily.
>
> Sorry if I say stupid or trivial things, I did not really try to learn
> how these things are currently done in Blues..
the answer for all this stuff will be D-BUS.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* [PATCH 2.4.25-pre7] Fix it8181 compile
From: Bernhard Rosenkraenzer @ 2004-01-27 14:12 UTC (permalink / raw)
To: marcelo.tosatti, linux-kernel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 295 bytes --]
The it8181 framebuffer addition in 2.4.25-pre7 is incomplete - the
attached patch is needed in addition to the one that's in.
LLaP
bero
--
Ark Linux - Linux for the masses
http://www.arklinux.org/
Redistribution and processing of this message is subject to
http://www.arklinux.org/terms.php
[-- Attachment #2: it8181 missing part --]
[-- Type: APPLICATION/X-BZIP2, Size: 9229 bytes --]
^ permalink raw reply
* Re: NAT before IPsec with 2.6
From: Henrik Nordstrom @ 2004-01-27 14:12 UTC (permalink / raw)
To: Harald Welte; +Cc: Willy Tarreau, Tom Eastep, Michal Ludvig, netfilter-devel
In-Reply-To: <20040127130739.GR11761@sunbeam.de.gnumonks.org>
On Tue, 27 Jan 2004, Harald Welte wrote:
> > My view of where hooks should be for IPSec:
> >
> > (Client) -> Gateway -> (Gateway)
> >
> > 1. PREROUTING, original client packet
> > 2. FORWARD, original client packet. Destination the IPSec SPI
> > 3. POSTROUTING, original client packet. Destination the IPSec SPI
> > 4. OUTPUT, ESP packet. Preferably with some preserved information about
> > the original packet attached.
> > 5. POSTROUTING, ESP packet.
>
> I agree to all but 4. My proposal was PREROUTING, yours OUTPUT.
It is very hard to distinguis the different IPSec cases here. Save of
adding yet another hook for encapsulated and to be decapsulated packets
OUTPUT(/INPUT) is the closest match in my opinion. The packet it sees is
the packet from this IPSec endpoint to the other IPSec endpoint on the
IPSec SPI connection between the two.
The packet inside may be a forwarded packet or locally generated, it's all
the same. The ESP is an exchange between the two endpoints OUTPUT ->
POSTROUTING <-net-> PREROUTING -> INPUT
Use of PREROUTING introduces a completely new semantic unless you want to
also call FORWARD on these packets which I do not think is appropriate.
If introducing new hooks then we would have
XXXX -> POSTROUTING <-net-> PREROUTING -> YYYY
if XXXX and YYYY can be the same hook name in this case or not I'll leave
to the core team to ponder upon?
What exacly is the semantical problem of using OUTPUT/INPUT? In my view
the ESP/AH packet is locally generated, and belongs to a connection with a
local endpoint.
Regards
Henrik
^ permalink raw reply
* reiserfsprogs 3.6.11 compile failure. 3.6.12-pre3 compiles ok
From: Philippe Gramoullé @ 2004-01-27 14:13 UTC (permalink / raw)
To: reiserfs
Hi,
While installing a box to start playing with reiser4 i got a compile error
while trying to build reiserfsprogs 3.6.11. This the first time this happens as
i had already compiled it successfully on other Debian Unstable boxes.
I guess i may be because of a newly installed development package that breaks
some macro.
Reiserfsprogs 3.6.12-pre3 compiles fine.
Thanks,
Philippe
boogie:/usr/src/reiserfsprogs-3.6.11# make
Making all in include
make[1]: Entering directory `/usr/src/reiserfsprogs-3.6.11/include'
make all-am
make[2]: Entering directory `/usr/src/reiserfsprogs-3.6.11/include'
make[2]: Leaving directory `/usr/src/reiserfsprogs-3.6.11/include'
make[1]: Leaving directory `/usr/src/reiserfsprogs-3.6.11/include'
Making all in lib
make[1]: Entering directory `/usr/src/reiserfsprogs-3.6.11/lib'
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -Wall -MT io.o -MD -MP -MF ".deps/io.Tpo" \
-c -o io.o `test -f 'io.c' || echo './'`io.c; \
then mv ".deps/io.Tpo" ".deps/io.Po"; \
else rm -f ".deps/io.Tpo"; exit 1; \
fi
if gcc -DHAVE_CONFIG_H -I. -I. -I../include -g -O2 -Wall -MT misc.o -MD -MP -MF ".deps/misc.Tpo" \
-c -o misc.o `test -f 'misc.c' || echo './'`misc.c; \
then mv ".deps/misc.Tpo" ".deps/misc.Po"; \
else rm -f ".deps/misc.Tpo"; exit 1; \
fi
misc.c: In function `count_blocks':
misc.c:431: error: parse error before '[' token
make[1]: *** [misc.o] Error 1
make[1]: Leaving directory `/usr/src/reiserfsprogs-3.6.11/lib'
make: *** [all-recursive] Error 1
boogie:/usr/src/reiserfsprogs-3.6.11#
^ permalink raw reply
* Re: [PATCH 2/2] vfsmount_lock / mnt_parent
From: Maneesh Soni @ 2004-01-27 14:17 UTC (permalink / raw)
To: Mike Waychison; +Cc: LKML, Al Viro, Ian Kent
In-Reply-To: <40159DC7.9080504@sun.com>
On Mon, Jan 26, 2004 at 11:11:31PM +0000, Mike Waychison wrote:
> The attached patch ensures that we grab vfsmount_lock when grabbing a
> reference to mnt_parent in follow_up and follow_dotdot.
>
> We also don't need to access ->mnt_parent in follow_mount and
> __follow_down to mntput because we already the parent pointer on the stack.
>
>
As pointed by Viro on IRC, there are other places where we access/use
mnt_parent without any protection. IIUC this needs either vfsmount_lock or the
namespace sem for protection. I did audit such places and hope not missed
anything else.
One such place is in autofs4's is_vfsmnt_tree_busy() routine. I hope Ian still
has the expire patch which corrects it. Didn't know why this patch never hit
lkml.
IMO do_kern_mount() probably don't need any protection for mnt_parent as it is
still initializing the vfsmount struct.
The other remaining place is m68k/atari/stram.c:swap_init() where it is
initializing a static vfsmount struct, so again IMO no lock required here.
Thanks,
Maneesh
--
Maneesh Soni
Linux Technology Center,
IBM Software Lab, Bangalore, India
email: maneesh@in.ibm.com
Phone: 91-80-5044999 Fax: 91-80-5268553
T/L : 9243696
^ permalink raw reply
* List noise.
From: David Woodhouse @ 2004-01-27 14:18 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
All this noise on the list would be so easily avoided if the list wasn't
accepting messages without a Message-ID, and wasn't accepting bounces.
It's not hard -- it'd take _moments_ to protect the list against this.
--
dwmw2
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [ANN] ALSA-native sfxload program
From: Takashi Iwai @ 2004-01-27 14:18 UTC (permalink / raw)
To: alsa-user; +Cc: alsa-devel
Hi,
I added a new interface to ALSA 1.0.2 for handling the SoundFont file
without OSS sequencer emulation. The latest awesfx package,
ver.0.5.0, includes a new program "asfxload" for that. As you imagine
easily, it's the ALSA-native sfxload program.
It works just like sfxload but loads via ALSA-native hwdep device.
No new features, no new bugs :)
Also, awesfx is now packaged with GNU auto-tools. You can use
configure script like others.
The web page is at
http://www.alsa-project.org/~iwai/awedrv.html#Utils
The tarball is at
http://www.alsa-project.org/~iwai/awesfx-0.5.5.tar.gz
ciao,
Takashi
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* [U-Boot-Users] U-Boot with gcc-3.3.2 and ARM926EJS Targets fails due to __udiv0
From: Markus Pietrek @ 2004-01-27 14:24 UTC (permalink / raw)
To: u-boot
Hi folks,
I'm currently porting U-Boot 1.0.0 to a NetSilicon NS9750 (ARM926EJS core).
This port is partly derived from board/omap1610inn. The compiler is
gcc-3.3.2, taken from the uClibc toolchain.
For my target the compiler is using his internal libgcc.a:__div0 routine which
of course fails (it's an SWI instruction). But compiling U-Boot for an
smdk2410 platform with the same compiler uses the correct U-Boot's own __div0
code. I can't see any relevant differences in both build lines.
Can anyone help me? And is it really necessary to include libgcc.a?
The build line for the NS9750:
========================
UNDEF_SYM=`arm-linux-objdump -x board/ns9750dev/libns9750dev.a
cpu/arm926ejs/libarm926ejs.a lib_arm/libarm.a fs/jffs2/libjffs2.a
fs/fdos/libfdos.a fs/fat/libfat.a net/libnet.a disk/libdisk.a rtc/librtc.a
dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a
post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a |sed -n -e
's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
arm-linux-ld -Bstatic -T
/targets/ewp/LxMOD/build/apps/u-boot-1.0.0/board/ns9750dev/u-boot.lds -Ttext
0x00F80000 $UNDEF_SYM cpu/arm926ejs/start.o \
--start-group board/ns9750dev/libns9750dev.a
cpu/arm926ejs/libarm926ejs.a lib_arm/libarm.a fs/jffs2/libjffs2.a
fs/fdos/libfdos.a fs/fat/libfat.a net/libnet.a disk/libdisk.a rtc/librtc.a
dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a
post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a -L
/usr/local/LxNETES-3/arm-linux/lib/gcc-lib/arm-linux/3.3.2 -lgcc --end-group
\
-Map u-boot.map -o u-boot
========================
The relevant entry in u-boot.map for __div0:
===========================
/usr/local/LxNETES-3/arm-linux/lib/gcc-lib/arm-linux/3.3.2/libgcc.a(_udivsi3.o)
drivers/libdrivers.a(serial_ns9750.o)
(__udivsi3)
/
Compilation
============================
The build line for SMDK2410
=======================-
UNDEF_SYM=`arm-linux-objdump -x board/smdk2410/libsmdk2410.a
cpu/arm920t/libarm920t.a lib_arm/libarm.a fs/jffs2/libjffs2.a
fs/fdos/libfdos.a fs/fat/libfat.a net/libnet.a disk/libdisk.a rtc/librtc.a
dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a
post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a |sed -n -e
's/.*\(__u_boot_cmd_.*\)/-u\1/p'|sort|uniq`;\
arm-linux-ld -Bstatic -T
/targets/ewp/LxMOD/build/apps/u-boot.smdk/board/smdk2410/u-boot.lds -Ttext
0x33F80000 $UNDEF_SYM cpu/arm920t/start.o \
--start-group board/smdk2410/libsmdk2410.a
cpu/arm920t/libarm920t.a lib_arm/libarm.a fs/jffs2/libjffs2.a
fs/fdos/libfdos.a fs/fat/libfat.a net/libnet.a disk/libdisk.a rtc/librtc.a
dtt/libdtt.a drivers/libdrivers.a drivers/sk98lin/libsk98lin.a post/libpost.a
post/cpu/libcpu.a common/libcommon.a lib_generic/libgeneric.a -L
/usr/local/LxNETES-3/arm-linux/lib/gcc-lib/arm-linux/3.3.2 -lgcc --end-group
\
-Map u-boot.map -o u-boot
===================
The relevant entry in u-boot.map for __div0:
====================
lib_arm/libarm.a(_udivsi3.o) cpu/arm920t/libarm920t.a(speed.o) (__udivsi3)
--
Markus Pietrek
FS Forth-Systeme GmbH
Phone: +49 (7667) 908 145, FAX +49 (7667) 908 221
^ permalink raw reply
* Re: udev rule for usb printer
From: Bob Barry @ 2004-01-27 14:24 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <200401211924.08672.bobb@absamail.co.za>
Greg and Kay -
Thank you both for answering all my questions of this thread in the
most comprehensive possible way: udev-015 is installed and
working beautifully. My usb printer rule now works, and udevinfo
is really useful now.
Kay -
A few small observations about udevinfo:
- when I run udevinfo -h, the "-V" line displayed is:
-V print udev version
it should be
-V print udevinfo version
'cuz that's what it gives when I run udevinfo -V
- I'd suggest a default "all" option for query, to show
the entire database entry of the specified node,
as is shown by udevinfo -d
- the man page does not mention the -a option
- for newbies, a few example command lines
would be useful
Best Regards,
Bob
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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
* Re: [Bluez-devel] Windows Port
From: Marcel Holtmann @ 2004-01-27 14:25 UTC (permalink / raw)
To: acr; +Cc: BlueZ Mailing List
In-Reply-To: <46161.80.63.28.114.1075214415.squirrel@acroberts.com>
Hi Antony,
> Thanks for the answer. I don't see any reason why BlueZ can't be
> implemented on Windows. Obviously the hardware drivers will have to be
> completely rewritten, but surely the tricky stuff (L2CAP and RFCOMM) can
> be used in a Windows environment?
you have to rewrite all kernel stuff including L2CAP and RFCOMM. Take a
look at the source code of the kernel (for example net/bluetooth/) and
you will see that the code is full of Linux specific API calls. It is
much more easier to write a Bluetooth stack from scratch than porting
BlueZ to the Windows platform.
Regards
Marcel
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* Re: [LARTC] NEW imq driver
From: Philip Thiem @ 2004-01-27 14:28 UTC (permalink / raw)
To: lartc
In-Reply-To: <002a01c3e466$bb7f8700$030aa8c0@t>
[-- Attachment #1: Type: text/plain, Size: 1108 bytes --]
[snip]
> I noticed that with my trafic counter. internal trafic grew to enormous
> levels 10X more than it can be. In reality there was almost no output at
> all.
> so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on
> 100mb/s it probably can kill computer (not tested).
>
> Seems imq have similar problem even if driver itself have no leaks kernel
> consumes all resousces on resnending droped packets so that computer stops
> responding
[snip]
Just curious, I suppose you had the same setup on the original IMQ? If not,
my point is moot. But if so and if the problem could be verified, it would
appear to me that there is less of a problem with the old patch(except
for features), and more of a problem with the inherent nature of what
is being attempting. Meaning that a set of assumptions made by the network
layer developers is being invalidated. For example, local outbound traffic
being policed instead of shaped.
Philip Thiem -- Icequake.net Administrator
Isn't it obvious lumberjacks love traffic lights?
GPG Pub Key Archived at wwwkeys.us.pgp.net
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* linux-2.4-benh compiling error
From: Christian Kujau @ 2004-01-27 14:30 UTC (permalink / raw)
To: linuxppc-dev
hi,
i was about to compile linux-2.4-benh (fresh tree fetched via rsync)
when errors occured:
[...]
make[3]: Entering directory
`/data/MP3/scratch/kernel/linux-2.4-benh/drivers/char'
gcc -D__KERNEL__ -I/data/MP3/scratch/kernel/linux-2.4-benh/include -Wall
- -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
- -fomit-frame-pointer -I/data/MP3/scratch/kernel/linux-2.4-benh/arch/ppc
- -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized
- -mmultiple -mstring -nostdinc -iwithprefix include
- -DKBUILD_BASENAME=defkeymap -c -o defkeymap.o defkeymap.c
defkeymap.c:1: error: parse error before "defkeymap"
In file included from
/data/MP3/scratch/kernel/linux-2.4-benh/include/linux/types.h:15,
~ from defkeymap.c:6:
/data/MP3/scratch/kernel/linux-2.4-benh/include/linux/posix_types.h:38:
warning: type defaults to `int' in declaration of `__kernel_fd_set'
/data/MP3/scratch/kernel/linux-2.4-benh/include/linux/posix_types.h:38:
warning: data definition has no type or storage class
line-wrapping sucks, heres the full log and more info:
http://nerdbynature.de/bits/sheep/2.4.24-benh/make.log
http://nerdbynature.de/bits/sheep/2.4.24-benh/config
http://nerdbynature.de/bits/sheep/2.4.24-benh/ver_linux
i was told the 2.4-benh tree could fix some PReP annoyances (sp?) too,
so i wanted to try it out.
Thank you for your time,
Christian.
- --
BOFH excuse #259:
Someone's tie is caught in the printer, and if anything else gets
printed, he'll be in it too.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: pmdisk working on ppc (WAS: Help port swsusp to ppc)
From: Michael Schmitz @ 2004-01-27 14:32 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Michael Schmitz, Pavel Machek, Hugang, Patrick Mochel,
Nigel Cunningham, ncunningham, linuxppc-dev list
In-Reply-To: <1075199877.5659.190.camel@gaston>
> > I don't mind the wait for memory being freed. Copying more pages with
> > interrupts disabled would mean a higher chance for PMU lockup, won't it?
>
> It's also possible that there is a bug and it just crashes :)
>
> Also, I do suspend devices before the page copy, and I quickly hacked a
> PMU sysdev that should suspend ADB interrupts (at least) so that should
> be fine, except if you have a brightness request in flight maybe ?
I haven't. I've added another pmu_suspend/pmu_resume around the bulk of
pmdisk_save, that seems to have improved things (but not completely). It's
executed outside your sysdev calls, so it shouldn't really improve things.
> The whole PMU suspend thing must be reworked I suppose. (And the battery
> monitoring thing "paused" as well, we must wait for async PMU requests,
> that is at least battery requests and backlight ones to stop)
Battery requests might have been underway; pmud is running. If I read
pmu_suspend() right, pending battery requests should result in pmu_suspend
waiting for them to finish?
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [U-Boot-Users] tftpboot of BIG file fails !
From: Josef Baumgartner @ 2004-01-27 14:38 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20040127065737.CB062C108D@atlas.denx.de>
On Tuesday 27 January 2004 07:57, Wolfgang Denk wrote:
> In message <01a401c3e2a9$c29a0510$6706a8c0@Rupesh> you wrote:
> > I find a typical problem downloading a BIG ( 4MB) linux image to the
> > SDRAM
>
> I don't think this is a typical problem. On contrary, it is a very
> UNtypical problem since this has always been working fine on many,
> many boards.
>
> > using u-boot's _tftpboot_ command.
> > The Linux image is Linked at 0x20000.
>
> Then your Linux image is broken. You must not change the kernel's
> link address unless you know exactly what you are doing. This means
> that for example on PowerPC the kernel will be linked for (virtual)
> address 0xC0000000 and started at (physical) address 0x00000000.
Seems to be uClinux for Motorola Coldfire. Therefore it's ok.
>
> > My u-boot is liked at 0x3e0000 (I understaood this from the following two
> > macros)
> > TEXT_BASE = 0x3E0000
> > CFG_MONITOR_BASE = 0x3E0000
>
> Then your port of U-Boot is seriously broken.
>
> I would like to point out that NONE of the configurations in the
> public source tree uses such a broken definition.
In the current Coldfire 5272 port u-boot will be loaded to 0x3e0000 by colilo
and started there.
>
> > So I reconfigured the macros to link the u-boot on _top_ of the SDRAM
> > (SDRAM map is 0x00000000 to 0x01000000)
>
> A correctly configured U-Boot will automatically copy itself at the
> end of the RAM (at least on PPC).
Yes, in my new 5272 port u-boot relocates itself to the end of RAM.
>
> > But still I face the problem of not able to download the BIG image.
>
> You probably have other problems in your port.
>
> > Dows the tftp boot itself restrict the size of the file to be downloaded
> > ?
>
> Yes. The current implementation puts a limit at 16 MB.
>
> Best regards,
>
> Wolfgang Denk
Best regards,
Josef Baumgartner
^ permalink raw reply
* Re: List noise.
From: Dave Jones @ 2004-01-27 14:41 UTC (permalink / raw)
To: David Woodhouse; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1075213084.1633.95.camel-8OOqt/S+jKAjOxct69p1dh/sF2h8X+2i0E9HWUfgJXw@public.gmane.org>
On Tue, Jan 27, 2004 at 02:18:05PM +0000, David Woodhouse wrote:
> All this noise on the list would be so easily avoided if the list wasn't
> accepting messages without a Message-ID, and wasn't accepting bounces.
>
> It's not hard -- it'd take _moments_ to protect the list against this.
if you had control over the MTA, yes.
Sourceforget lists don't offer this power sadly.
Dave
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Marvell MV64340 documentation.
From: Pavel Kiryukhin @ 2004-01-27 14:45 UTC (permalink / raw)
To: linux-mips; +Cc: Pavel Kiryukhin
In-Reply-To: <40166BE8.2030009@mips.com>
Hi all,
is there any available documentation on Marvell MV64340 system controller?
Any links will be appreciated!
===============
Regards,
Pavel Kiryukhin,
RTSoft
^ permalink raw reply
* BK-kernel-tools/shortlog update
From: Matthias Andree @ 2004-01-27 14:46 UTC (permalink / raw)
To: torvalds, marcelo.tosatti; +Cc: linux-kernel, matthias.andree, samel
Hello Linus,
you can either use "bk receive" to patch with this mail,
or you can
Pull from: bk://krusty.dt.e-technik.uni-dortmund.de/BK-kernel-tools
or in cases of dire need, you can apply the patch below.
BK: Parent repository is http://bktools.bkbits.net/bktools
Patch description:
ChangeSet@1.120, 2004-01-27 15:45:18+01:00, matthias.andree@gmx.de
Remove 3 duplicate lines from hash.
Add address mapping for Francis Wiran.
Add new "What am I about to pull?" EXAMPLE.
Matthias
------------------------------------------------------------------------
##### DIFFSTAT #####
# shortlog | 10 ++++++----
# 1 files changed, 6 insertions(+), 4 deletions(-)
##### GNUPATCH #####
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
# 2004/01/27 15:45:18+01:00 matthias.andree@gmx.de
# Remove 3 duplicate lines from hash.
# Add address mapping for Francis Wiran.
# Add new "What am I about to pull?" EXAMPLE.
#
# shortlog
# 2004/01/27 15:45:17+01:00 matthias.andree@gmx.de +6 -4
# Remove 3 duplicate lines from hash.
# Add address mapping for Francis Wiran.
# Add new "What am I about to pull?" EXAMPLE.
#
diff -Nru a/shortlog b/shortlog
--- a/shortlog Tue Jan 27 15:46:01 2004
+++ b/shortlog Tue Jan 27 15:46:01 2004
@@ -8,7 +8,7 @@
# Tomas Szepe <szepe@pinerecords.com>
# Vitezslav Samel <samel@mail.cz>
#
-# $Id: lk-changelog.pl,v 0.221 2004/01/23 10:24:51 vita Exp $
+# $Id: lk-changelog.pl,v 0.224 2004/01/27 14:40:49 emma Exp $
# ----------------------------------------------------------------------
# Distribution of this script is permitted under the terms of the
# GNU General Public License (GNU GPL) v2.
@@ -471,7 +471,6 @@
'dmccr:us.ibm.com' => 'Dave McCracken',
'dmo:osdl.org' => 'Dave Olien',
'doj:cubic.org' => 'Dirk Jagdmann',
-'doj:cubic.org' => 'Dirk Jagdmann',
'dok:directfb.org' => 'Denis Oliver Kropp',
'dougg:torque.net' => 'Douglas Gilbert',
'drb:med.co.nz' => 'Ross Boswell',
@@ -550,6 +549,7 @@
'fnm:fusion.ukrsat.com' => 'Nick Fedchik',
'focht:ess.nec.de' => 'Erich Focht',
'fokkensr:fokkensr.vertis.nl' => 'Rolf Fokkens',
+'francis.wiran:hp.com' => 'Francis Wiran',
'franz.sirl-kernel:lauterbach.com' => 'Franz Sirl',
'franz.sirl:lauterbach.com' => 'Franz Sirl',
'frival:zk3.dec.com' => 'Peter Rival',
@@ -583,7 +583,6 @@
'gl:dsa-ac.de' => 'Guennadi Liakhovetski',
'glee:gnupilgrims.org' => 'Geoffrey Lee', # lbdb
'glenn:aoi-industries.com' => 'Glenn Burkhardt',
-'glenn:aoi-industries.com' => 'Glenn Burkhardt',
'gnb:alphalink.com.au' => 'Greg Banks',
'go:turbolinux.co.jp' => 'Go Taniguchi',
'gone:us.ibm.com' => 'Patricia Gaughen',
@@ -1138,7 +1137,6 @@
'pdelaney:lsil.com' => 'Pam Delaney',
'pe1rxq:amsat.org' => 'Jeroen Vreeken',
'pebl:math.ku.dk' => 'Peter Berg Larsen',
-'pebl:math.ku.dk' => 'Peter Berg Larsen',
'pee:erkkila.org' => 'Paul E. Erkkila',
'pekon:informatics.muni.cz' => 'Petr Konecny',
'per.winkvist:telia.com' => 'Per Winkvist',
@@ -2327,6 +2325,10 @@
=head1 EXAMPLES
=over
+
+=item "What am I about to pull?"
+
+bk changes -R -m | lk-changelog.pl | less
=item Reformat ChangeLog-2.5.17, displaying all changes grouped by
their author (that is the default mode, but we specify it anyways),
##### BKPATCH #####
This BitKeeper patch contains the following changesets:
1.120
## Wrapped with gzip_uu ##
M'XL( *EY%D ]U46V^;,!A]CG_%I[92'EJ(;6P(2'2])-VJ=EJ5J>H>]N*
M$U (^Q<)O'C9Q*E53IUTRY/ PMLZ^-POG..? R/6C91KQ3&9+G0KJC21DIT
M#!^4-E%O7F[<M%M.E+++@5YJ.5C(II+%X.K.#F>W<(Q2A4:V\$&8)(.5;'34
M(Z[WO&.^U3+J3<;O'^\O)PC%,5QGHIK+S]) '".CFI4H4GU1RVJ^S"O7-*+2
MI33"3539/M>V%&-J;T(][/.PI:'/>2NIY#QA1$R#82 3^@*7J5*Z2J>%JYKY
M(0RS(#ZFS"/#UDZYAT9 7$(Q8#; 9$ #(#QB/"+#4TPBC.&52A<[=>"4@(/1
M%?SC'JY1 A-9JI4$#])E7>2),!**O)(:9HTJ(1,Z<VW599J"2"TEK2W'NLZK
M.<Q4 S?V_TFNX2FWDWUA)==P])0) Z*$6Q!3M326.M3+HGAW!.,OEQ\?[L<N
MN@-""4</+SXAYS<OA+# Z!P.W3A416>J,86:[T3A9(@#%EA'/!*$O)W)4,R2
M (<"RU1,TS<L.$#I? T(8YP$K4]PZ&_3MJ\X"-M?\WDK:*_Y['/FDP#C;<Y"
M[X>8!;^(F0\.^P]CMO/H$SC->M,-9V-#MQ?P#S(W(@0(NMT^C^'D-HV@6#C)
M5A:+Z-;%V0JP2RF#SIV]!RQB.&(AR+(4,-[4<()&+& =%.?4OOJS79_NNNLS
MRNI.[C[$Y] _4*!_AD9\Z-LO+!.VY4(]&@)#7U&<&UG^1!=;,EW CJL&9P).
A">UK^MV.]>#EM$TRF2STLHQ]D81A.DO0=RWV_4/8!0
^ permalink raw reply
* lk-changelog.pl 0.224
From: Matthias Andree @ 2004-01-27 14:46 UTC (permalink / raw)
To: torvalds, marcelo.tosatti; +Cc: linux-kernel, matthias.andree
This is a semi-automatic announcement.
lk-changelog.pl aka. shortlog version 0.224 has been released.
This script is used by Linus and Marcelo to rearrange and reformat BK
ChangeSet logs into a more human-readable format, and the official
repository is Parent repository is http://bktools.bkbits.net/bktools
As the script has grown large, this mail only contains a diff against
the last released version.
You can always download the full script and GPG signatures from
http://mandree.home.pages.de/linux/kernel/
My thanks go to Vitezslav Samel who has spent a lot of time on digging
out the real names for addresses sending in BK ChangeSets.
Note that your mailer must be MIME-capable to save this mail properly,
because it is in the "quoted-printable" encoding.
= <- if you see just an equality sign, but no "3D", your mailer is fine.
= <- if you see 3D on this line, then upgrade your mailer or pipe this mail
= <- into metamail.
--
A sh script on behalf of Matthias Andree
-------------------------------------------------------------------------
Changes since last release:
----------------------------
revision 0.224
date: 2004/01/27 14:40:49; author: emma; state: Exp; lines: +5 -1
New EXAMPLE added, 'What am I about to pull?'.
----------------------------
revision 0.223
date: 2004/01/27 11:47:16; author: vita; state: Exp; lines: +2 -1
add Francis Wiran's address
----------------------------
revision 0.222
date: 2004/01/26 13:51:11; author: vita; state: Exp; lines: +3 -1
merge Linus' additions
----------------------------
revision 0.221
date: 2004/01/23 10:24:51; author: vita; state: Exp; lines: +5 -1
4 new addresses
=============================================================================
Index: lk-changelog.pl
===================================================================
RCS file: /var/CVS/lk-changelog/lk-changelog.pl,v
retrieving revision 0.221
retrieving revision 0.224
diff -u -r0.221 -r0.224
--- lk-changelog.pl 23 Jan 2004 10:24:51 -0000 0.221
+++ lk-changelog.pl 27 Jan 2004 14:40:49 -0000 0.224
@@ -8,7 +8,7 @@
# Tomas Szepe <szepe@pinerecords.com>
# Vitezslav Samel <samel@mail.cz>
#
-# $Id: lk-changelog.pl,v 0.221 2004/01/23 10:24:51 vita Exp $
+# $Id: lk-changelog.pl,v 0.224 2004/01/27 14:40:49 emma Exp $
# ----------------------------------------------------------------------
# Distribution of this script is permitted under the terms of the
# GNU General Public License (GNU GPL) v2.
@@ -267,6 +267,7 @@
'barryn:pobox.com' => 'Barry K. Nathan', # lbdb
'bart.de.schuyer:pandora.be' => 'Bart De Schuymer',
'bart.de.schuymer:pandora.be' => 'Bart De Schuymer',
+'bart:samwel.tk' => 'Bart Samwel',
'bbosch:iphase.com' => 'Bradley A. Bosch',
'bcollins:debian.org' => 'Ben Collins',
'bcrl:bob.home.kvack.org' => 'Benjamin LaHaise',
@@ -548,6 +549,7 @@
'fnm:fusion.ukrsat.com' => 'Nick Fedchik',
'focht:ess.nec.de' => 'Erich Focht',
'fokkensr:fokkensr.vertis.nl' => 'Rolf Fokkens',
+'francis.wiran:hp.com' => 'Francis Wiran',
'franz.sirl-kernel:lauterbach.com' => 'Franz Sirl',
'franz.sirl:lauterbach.com' => 'Franz Sirl',
'frival:zk3.dec.com' => 'Peter Rival',
@@ -1106,6 +1108,7 @@
'p_gortmaker:yahoo.com' => 'Paul Gortmaker',
'pablo:menichini.com.ar' => 'Pablo Menichini',
'pam.delaney:lsil.com' => 'Pamela Delaney',
+'panagiotis.issaris:mech.kuleuven.ac.be' => 'Panagiotis Issaris',
'paschal:rcsis.com' => 'David Paschal',
'pasky:ucw.cz' => 'Petr Baudis',
'patch:luckynet.dynu.com' => '"Lightweight Patch Manager"', # lbdb
@@ -2322,6 +2325,10 @@
=head1 EXAMPLES
=over
+
+=item "What am I about to pull?"
+
+bk changes -R -m | lk-changelog.pl | less
=item Reformat ChangeLog-2.5.17, displaying all changes grouped by
their author (that is the default mode, but we specify it anyways),
^ permalink raw reply
* Re: List noise.
From: Matthew Wilcox @ 2004-01-27 14:47 UTC (permalink / raw)
To: Dave Jones; +Cc: David Woodhouse, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20040127144159.GP29296-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, Jan 27, 2004 at 02:41:59PM +0000, Dave Jones wrote:
> On Tue, Jan 27, 2004 at 02:18:05PM +0000, David Woodhouse wrote:
> > All this noise on the list would be so easily avoided if the list wasn't
> > accepting messages without a Message-ID, and wasn't accepting bounces.
> >
> > It's not hard -- it'd take _moments_ to protect the list against this.
>
> if you had control over the MTA, yes.
> Sourceforget lists don't offer this power sadly.
Another good reason to ditch sourceforgrot.
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
because the adverts clearly weren't enough.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
^ permalink raw reply
* Re: bk pull on ia64 linux tree
From: Martin Hicks @ 2004-01-27 14:49 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <Pine.LNX.4.58.0401121658240.14305@evo.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
On Mon, Jan 26, 2004 at 05:37:14PM -0800, David Mosberger wrote:
> Hi Linus,
>
> please do a
>
> bk pull http://lia64.bkbits.net/to-linus-2.5
>
Linus, David,
I accidentally left a debug printk in the sn2 timer_interrupt(). Here
is a fix. I sent an updated patch to David yesterday, but I guess it
didn't make it.
Please apply.
Thanks,
mh
--
Martin Hicks Wild Open Source Inc.
mort@wildopensource.com 613-266-2296
[-- Attachment #2: sn2-timer-interrupt-fixup.diff --]
[-- Type: text/plain, Size: 1002 bytes --]
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.1500 -> 1.1501
# arch/ia64/sn/kernel/sn2/timer_interrupt.c 1.1 -> 1.2
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 04/01/27 mort@green.i.bork.org 1.1501
# Remove debug printk from sn2 timer_interrupt
# --------------------------------------------
#
diff -Nru a/arch/ia64/sn/kernel/sn2/timer_interrupt.c b/arch/ia64/sn/kernel/sn2/timer_interrupt.c
--- a/arch/ia64/sn/kernel/sn2/timer_interrupt.c Tue Jan 27 09:42:06 2004
+++ b/arch/ia64/sn/kernel/sn2/timer_interrupt.c Tue Jan 27 09:42:06 2004
@@ -48,7 +48,6 @@
if (!pda->hb_count--) {
pda->hb_count = HZ/2;
set_led_bits(pda->hb_state ^= LED_CPU_HEARTBEAT, LED_CPU_HEARTBEAT);
- printk("Blink\n");
}
if (enable_shub_wars_1_1()) {
^ permalink raw reply
* MIPS Kernel size
From: kip.r2 @ 2004-01-27 14:51 UTC (permalink / raw)
To: linux-mips
What will be the approximate size for a minimal MIPS kernel?
^ permalink raw reply
* [PATCH] toshiba_acpi 0.17
From: John Belmonte @ 2004-01-27 14:55 UTC (permalink / raw)
To: Brown, Len; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
Len,
Please apply this patch, which will yield version 0.17 of the
toshiba_acpi driver against the head of the Linux 2.4 and 2.5
development trees.
Changelog:
* Fix remote chance of invalid buffer access in write_video.
* Support alternate HCI method path (recent "Phoenix BIOS" Toshiba's).
* Signal more proc-write errors.
* On proc-reads, report errors via printk instead of proc output.
* Add log level and driver name prefix to all printk's.
* Add missing __init and __exit function attributes.
* Be explicit about vars for which code relies on zero-init of BSS.
Regards,
-John
[-- Attachment #2: toshiba_acpi_0.17-linux_head.patch --]
[-- Type: text/x-patch, Size: 5893 bytes --]
diff -urN old/drivers/acpi/toshiba_acpi.c new/drivers/acpi/toshiba_acpi.c
--- old/drivers/acpi/toshiba_acpi.c 2004-01-27 09:09:12.000000000 -0500
+++ new/drivers/acpi/toshiba_acpi.c 2004-01-27 09:16:22.000000000 -0500
@@ -2,7 +2,7 @@
* toshiba_acpi.c - Toshiba Laptop ACPI Extras
*
*
- * Copyright (C) 2002-2003 John Belmonte
+ * Copyright (C) 2002-2004 John Belmonte
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -33,7 +33,7 @@
*
*/
-#define TOSHIBA_ACPI_VERSION "0.16"
+#define TOSHIBA_ACPI_VERSION "0.17"
#define PROC_INTERFACE_VERSION 1
#include <linux/kernel.h>
@@ -48,9 +48,15 @@
MODULE_DESCRIPTION("Toshiba Laptop ACPI Extras Driver");
MODULE_LICENSE("GPL");
+#define MY_LOGPREFIX "toshiba_acpi: "
+#define MY_ERR KERN_ERR MY_LOGPREFIX
+#define MY_NOTICE KERN_NOTICE MY_LOGPREFIX
+#define MY_INFO KERN_INFO MY_LOGPREFIX
+
/* Toshiba ACPI method paths */
#define METHOD_LCD_BRIGHTNESS "\\_SB_.PCI0.VGA_.LCD_._BCM"
-#define METHOD_HCI "\\_SB_.VALD.GHCI"
+#define METHOD_HCI_1 "\\_SB_.VALD.GHCI"
+#define METHOD_HCI_2 "\\_SB_.VALZ.GHCI"
#define METHOD_VIDEO_OUT "\\_SB_.VALX.DSSX"
/* Toshiba HCI interface definitions
@@ -121,6 +127,16 @@
*/
static int
+is_valid_acpi_path(const char* methodName)
+{
+ acpi_handle handle;
+ acpi_status status;
+
+ status = acpi_get_handle(0, (char*)methodName, &handle);
+ return !ACPI_FAILURE(status);
+}
+
+static int
write_acpi_int(const char* methodName, int val)
{
struct acpi_object_list params;
@@ -154,6 +170,8 @@
}
#endif
+static const char* method_hci /*= 0*/;
+
/* Perform a raw HCI call. Here we don't care about input or output buffer
* format.
*/
@@ -177,7 +195,7 @@
results.length = sizeof(out_objs);
results.pointer = out_objs;
- status = acpi_evaluate_object(0, METHOD_HCI, ¶ms,
+ status = acpi_evaluate_object(0, (char*)method_hci, ¶ms,
&results);
if ((status == AE_OK) && (out_objs->package.count <= HCI_WORDS)) {
for (i = 0; i < out_objs->package.count; ++i) {
@@ -215,7 +233,7 @@
return status;
}
-static struct proc_dir_entry* toshiba_proc_dir;
+static struct proc_dir_entry* toshiba_proc_dir /*= 0*/;
static int force_fan;
static int last_key_event;
static int key_event_valid;
@@ -270,7 +288,7 @@
p += sprintf(p, "brightness_levels: %d\n",
HCI_LCD_BRIGHTNESS_LEVELS);
} else {
- p += sprintf(p, "ERROR\n");
+ printk(MY_ERR "Error reading LCD brightness\n");
}
return p;
@@ -310,7 +328,7 @@
p += sprintf(p, "crt_out: %d\n", is_crt);
p += sprintf(p, "tv_out: %d\n", is_tv);
} else {
- p += sprintf(p, "ERROR\n");
+ printk(MY_ERR "Error reading video out status\n");
}
return p;
@@ -320,25 +338,31 @@
write_video(const char* buffer, unsigned long count)
{
int value;
- const char* buffer_end = buffer + count;
+ int remain = count;
int lcd_out = -1;
int crt_out = -1;
int tv_out = -1;
u32 hci_result;
int video_out;
- /* scan expression. Multiple expressions may be delimited with ; */
- do {
- if (snscanf(buffer, count, " lcd_out : %i", &value) == 1)
+ /* scan expression. Multiple expressions may be delimited with ;
+ *
+ * NOTE: to keep scanning simple, invalid fields are ignored
+ */
+ while (remain) {
+ if (snscanf(buffer, remain, " lcd_out : %i", &value) == 1)
lcd_out = value & 1;
- else if (snscanf(buffer, count, " crt_out : %i", &value) == 1)
+ else if (snscanf(buffer, remain, " crt_out : %i", &value) == 1)
crt_out = value & 1;
- else if (snscanf(buffer, count, " tv_out : %i", &value) == 1)
+ else if (snscanf(buffer, remain, " tv_out : %i", &value) == 1)
tv_out = value & 1;
/* advance to one character past the next ; */
- do ++buffer;
- while ((buffer < buffer_end) && (*(buffer-1) != ';'));
- } while (buffer < buffer_end);
+ do {
+ ++buffer;
+ --remain;
+ }
+ while (remain && *(buffer-1) != ';');
+ }
hci_read1(HCI_VIDEO_OUT, &video_out, &hci_result);
if (hci_result == HCI_SUCCESS) {
@@ -353,6 +377,8 @@
* video setting if something changed. */
if (new_video_out != video_out)
write_acpi_int(METHOD_VIDEO_OUT, new_video_out);
+ } else {
+ return -EFAULT;
}
return count;
@@ -369,7 +395,7 @@
p += sprintf(p, "running: %d\n", (value > 0));
p += sprintf(p, "force_on: %d\n", force_fan);
} else {
- p += sprintf(p, "ERROR\n");
+ printk(MY_ERR "Error reading fan status\n");
}
return p;
@@ -413,8 +439,9 @@
* some machines where system events sporadically
* become disabled. */
hci_write1(HCI_SYSTEM_EVENT, 1, &hci_result);
+ printk(MY_NOTICE "Re-enabled hotkeys\n");
} else {
- p += sprintf(p, "ERROR\n");
+ printk(MY_ERR "Error reading hotkey status\n");
goto end;
}
}
@@ -465,7 +492,7 @@
{ 0 , 0 , 0 },
};
-static acpi_status
+static acpi_status __init
add_device(void)
{
struct proc_dir_entry* proc;
@@ -483,7 +510,7 @@
return(AE_OK);
}
-static acpi_status
+static acpi_status __exit
remove_device(void)
{
ProcItem* item;
@@ -497,15 +524,19 @@
toshiba_acpi_init(void)
{
acpi_status status = AE_OK;
- int value;
u32 hci_result;
- /* simple device detection: try reading an HCI register */
- hci_read1(HCI_LCD_BRIGHTNESS, &value, &hci_result);
- if (hci_result != HCI_SUCCESS)
+ /* simple device detection: look for HCI method */
+ if (is_valid_acpi_path(METHOD_HCI_1))
+ method_hci = METHOD_HCI_1;
+ else if (is_valid_acpi_path(METHOD_HCI_2))
+ method_hci = METHOD_HCI_2;
+ else
return -ENODEV;
- printk("Toshiba Laptop ACPI Extras version %s\n", TOSHIBA_ACPI_VERSION);
+ printk(MY_INFO "Toshiba Laptop ACPI Extras version %s\n",
+ TOSHIBA_ACPI_VERSION);
+ printk(MY_INFO " HCI method: %s\n", method_hci);
force_fan = 0;
key_event_valid = 0;
^ permalink raw reply
* Re: [PATCH] kgdb-x86_64-support.patch for 2.6.2-rc1-mm3
From: Andi Kleen @ 2004-01-27 14:56 UTC (permalink / raw)
To: jim.houston; +Cc: akpm, george, amitkale, linux-kernel
In-Reply-To: <20040127030529.8F860C60FC@h00e098094f32.ne.client2.attbi.com>
On Mon, 26 Jan 2004 22:05:29 -0500 (EST)
Jim Houston <jim.houston@comcast.net> wrote:
>
> Hi Andrew,
>
> The attached patch updates my kgdb-x86_64-support.patch to work
> with linux-2.6.2-rc1-mm3.
Hi,
I already did this merge yesterday. Didn't you get mail?
>
> The conflicts seen with the old patch are the result of Andi Kleen
> pushing a portion of the patch to Linus. In particular my
> addition of .cfi directives to the x86_64 assembly files is
> now in Linus's tree.
>
> This version has also been tested (and now works) with Matt Mackall's
> kgdb over ethernet.
Hmm, It didn't work for me.
-Andi
^ 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.