* rq_data_dir() in linux/blkdev.h is redundant
From: Xiaogeng (Shawn) Jin @ 2003-01-10 2:37 UTC (permalink / raw)
To: linux-mtd, linuxppc-embedded
Hi,
When compiling linuxppc_2_4_devel (2.4.21-pre3) with the latest
MTD/JFFS2 code, I had such error posted in a previous message.
ppc_8xx-gcc -D__KERNEL__
-I/u/xjin/2_4_devel/Software/Linux/MPC855/linuxppc_2_4_
devel/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2
-fno-strict-aliasing
-fno-common -fomit-frame-pointer
-I/u/xjin/2_4_devel/Software/Linux/MPC855/linux
ppc_2_4_devel/arch/ppc -fsigned-char -msoft-float -pipe -ffixed-r2
-Wno-uninitia
lized -mmultiple -mstring -nostdinc -I
/opt/eldk2.0/usr/lib/gcc-lib/ppc-linux/
2.95.4/include -DKBUILD_BASENAME=mtdblock_core -c -o mtdblock-core.o
mtdblock-c
ore.c
In file included from
/u/xjin/2_4_devel/Software/Linux/MPC855/linuxppc_2_4_devel
/include/linux/blk.h:4,
from mtdblock-core.c:18:
/u/xjin/2_4_devel/Software/Linux/MPC855/linuxppc_2_4_devel/include/linux/blkdev.
h:147: parse error before `struct'
After traced down the problem, I found that it was caused by the
definition of rq_data_dir() in linux/blkdev.h. The definition is as
follows, which seems to be useless.
extern inline int rq_data_dir(struct request *rq)
{
if (rq->cmd == READ)
return READ;
else if (rq->cmd == WRITE)
return WRITE;
else {
BUG();
return -1;
}
}
Actually linux/mtd/compacmatmac.h defines rq_data_dir() as
#define rq_data_dir(x) ((x)->cmd)
if the kernel version is older than 2.5.0.
--
Shawn Jin
RedSwitch Inc.
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: jdow @ 2003-01-10 2:15 UTC (permalink / raw)
To: Chris Adams, linux-kernel
In-Reply-To: <20030109192432.A485131@hiwaay.net>
From: "Chris Adams" <cmadams@hiwaay.net>
> Once upon a time, Alan Cox <alan@lxorguk.ukuu.org.uk> said:
> >and of course Sally Floyd, and even Hedy Lamarr (bonus points for those
> >who know what her networking related patent is on)
>
> That's HEDLEY! Oh, but he doesn't have any patents.
No, it's Hedy Lamarr and she invented frequency hopping spread spectrum
with George Anthiel. I worked on one of the first practical implementations
of the concept back in the early 70s. Somehow it seems appropriate.
{^_^} Joanne, jdow@earthlink.net
^ permalink raw reply
* Re: FYI: Etherleak
From: Jeff Garzik @ 2003-01-10 2:08 UTC (permalink / raw)
To: Yan-Fa Li; +Cc: netdev, linux-kernel
In-Reply-To: <D71BEAC27500D51199DF0002B328BA8D4FBF2B@ivexs1.intruvert.com>
On Thu, Jan 09, 2003 at 05:49:47PM -0800, Yan-Fa Li wrote:
> An interesting report into frame-padding information leakage violations in
> ethernet drivers. The authors use linux drivers in their examples.
>
> http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf
Yes. All of those drivers are for ancient and/or obscure hardware
except three: rtl8139, epic100, and via-rhine.
There are fixes for those (and others) in testing right now, in fact :)
^ permalink raw reply
* Beginner questions about soundmodem and others
From: James Washer @ 2003-01-10 1:56 UTC (permalink / raw)
To: linux-hams
Perhaps I should have put these all in seperate mails... but here goes
1)I'm confused by this whole AX.25 kernel thing... I had assumed that (most) TNCs handled the AX.25 protocol themselves.
I understand that with a soundmodem, the linux system would have to do the AX.25, but what about if I use an off-the-shelf TNC ( kpc3 for example ). Does linux arrange to turn the AX.25 handling OFF in the TNC and do it in software?
2) Can I put more than one sound card in my linux box.. One for music, the other, perhaps multiple soundcards, for packet?
3) Anyone on this mailing list anywhere near Reno NV... I'd love to have someone local to work with to get started.
thanks
- jim kg7hh
^ permalink raw reply
* FYI: Etherleak
From: Yan-Fa Li @ 2003-01-10 1:49 UTC (permalink / raw)
To: netdev
An interesting report into frame-padding information leakage violations in
ethernet drivers. The authors use linux drivers in their examples.
http://www.atstake.com/research/advisories/2003/atstake_etherleak_report.pdf
[[HTML alternate version deleted]]
^ permalink raw reply
* RE: SELF: compile of util-linux
From: James Don @ 2003-01-10 1:43 UTC (permalink / raw)
To: James Don, 'linuxppc-embedded@lists.linuxppc.org'
Scratch question 2 ...
I thin the answer is that "patch" basically buts in the files necessary to
build a cross compiled version of "util-linux" .... after I patch I think
this will mean that the SED command will find some matches ...
I didn't need the "patch part" to build busy box (0.60.5) when I tried ...
so I thought I could skip it ...
I think anyways,
Jim
-----Original Message-----
From: James Don
Sent: Thursday, January 09, 2003 8:36 PM
To: linuxppc-embedded@lists.linuxppc.org
Subject: SELF: compile of util-linux
Hi,
I am just browsing through the SELF code ... and trying for kicks to make
"my own version" as an exercise to learn more about packages required for a
running embedded Linux system ...
So far I have ...
1.) Built uclibc
2.) Built busybox with uclibc gcc wrappers
3.) Built insmod with uclibc gcc wrappers
I am reading the compile of util-linux (see below item 1) ... I am
relatively new to linux so I have some questions (most of which are probably
stupid seeing as just started looking at this)...
1.) The "patch" part of the compile ... is it to add kernel support for what
I am compiling? If I managed to get a pre-built image to run on an unpatched
kernel what am I missing?
2.) When you run the "sed -e 's/XXX-powerpc-linux-/$(CROSS_PREFIX)/" I
assume this should go into the make sysyem and put the cross compiler in the
build ? ... sorry never used "sed" just skimmed the man page
3.) For kicks I have taken the tar ball I downloaded of util-linux (version
2.11y) and tried to compile it with the uclibc gcc wrappers (see item 2
below) ... now this does when I get to the "make part" ... it seems to die
because "configure" was not called ... but its not called from SELF's make
file either ??? If I call make from the util-linux directory it calls
configure ... but then uses my local 'cc' ...
Any tips would be great ;-) In the mean time I will keep digging and
hopefully see what's wrong with my script ;-)
Best regards,
Jim
item 1
============
$(LOGIN)/login-utils/login: $(LOGIN)/.patch
$(MAKE) -C $(LOGIN)/lib
$(MAKE) -C $(LOGIN)/login-utils login
$(LOGIN)/.patch: $(CONFIGURATION) \
$(TARBALLS)/util-linux-$(LOGIN_VERSION).tar.gz \
$(PATCHES)/util-linux-$(LOGIN_VERSION)-cross.$(P_SUFF) \
$(PATCHES)/util-linux-$(LOGIN_VERSION)-nosetproctitle.$(P_SUFF) \
$(CONFIG)/config.mk
rm -fr $(LOGIN)
cd $(BUILD) && \
gzip -cd $(TARBALLS)/util-linux-$(LOGIN_VERSION).tar.gz | tar xf -
cd $(LOGIN) && \
sed -e 's/XXX-powerpc-linux-/$(CROSS_PREFIX)/' \
$(PATCHES)/util-linux-$(LOGIN_VERSION)-cross.$(P_SUFF) | \
patch -p1 -b -z.cross && \
patch -p1 -b -z.no_sp
<$(PATCHES)/util-linux-$(LOGIN_VERSION)-nosetproctitle.$(P_SUFF) && \
touch .patch
item 2
==============
#!/usr/bin/bash
LOGIN_UTIL_VERSION=2.11y
LOGIN_BUILD_DIR=$HOME/ppcLoginUtil/
CROSS=powerper-uclibc-
echo LOGIN_BUILD_DIR=$LOGIN_BUILD_DIR
rm -fr $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION
tar xvfz $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION.tar.gz
cd $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION
sed -e 's/XXX-powerpc-linux-/$CROSS/' *
make -C $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION/lib
make -C $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION/login-utils login
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [PATCH] linux-2.5.55_timer-tsc-cleanups_A0
From: john stultz @ 2003-01-10 1:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: lkml
Linus, All,
This patch cleans up the timer_tsc code. It removes the unused use_tsc
variable and makes fast_gettimeoffset_quotient static (replacing it w/
cpu_khz in smpboot.c).
Please consider for acceptance.
thanks
-john
diff -Nru a/arch/i386/kernel/smpboot.c b/arch/i386/kernel/smpboot.c
--- a/arch/i386/kernel/smpboot.c Thu Jan 9 17:03:07 2003
+++ b/arch/i386/kernel/smpboot.c Thu Jan 9 17:03:07 2003
@@ -182,8 +182,6 @@
#define NR_LOOPS 5
-extern unsigned long fast_gettimeoffset_quotient;
-
/*
* accurate 64-bit/32-bit division, expanded to 32-bit divisions and 64-bit
* multiplication. Not terribly optimized but we need it at boot time only
@@ -223,7 +221,8 @@
printk("checking TSC synchronization across %u CPUs: ", num_booting_cpus());
- one_usec = ((1<<30)/fast_gettimeoffset_quotient)*(1<<2);
+ /* convert from kcyc/sec to cyc/usec */
+ one_usec = cpu_khz / 1000;
atomic_set(&tsc_start_flag, 1);
wmb();
diff -Nru a/arch/i386/kernel/timers/timer_tsc.c b/arch/i386/kernel/timers/timer_tsc.c
--- a/arch/i386/kernel/timers/timer_tsc.c Thu Jan 9 17:03:07 2003
+++ b/arch/i386/kernel/timers/timer_tsc.c Thu Jan 9 17:03:07 2003
@@ -19,7 +19,6 @@
extern int x86_udelay_tsc;
extern spinlock_t i8253_lock;
-static int use_tsc;
/* Number of usecs that the last interrupt was delayed */
static int delay_at_last_interrupt;
@@ -30,7 +29,7 @@
* Equal to 2^32 * (1 / (clocks per usec) ).
* Initialized in time_init.
*/
-unsigned long fast_gettimeoffset_quotient;
+static unsigned long fast_gettimeoffset_quotient;
static unsigned long get_offset_tsc(void)
{
@@ -267,7 +266,6 @@
unsigned long tsc_quotient = calibrate_tsc();
if (tsc_quotient) {
fast_gettimeoffset_quotient = tsc_quotient;
- use_tsc = 1;
/*
* We could be more selective here I suspect
* and just enable this for the next intel chips ?
^ permalink raw reply
* RE: detecting hyperthreading in linux 2.4.19
From: Pallipadi, Venkatesh @ 2003-01-09 23:26 UTC (permalink / raw)
To: Jason Lunz, linux-kernel
Systems running the latest RH, SuSE releases, with standard smp kernel
should see some entries in /proc/cpuinfo, which gives information about
HT configuration on the system. The latest 2.5 kernel also has similar
information in /proc/cpuinfo.
The entries look something like:
Physical processor ID : 0
Number of siblings : 2
Unfortunately, 2.4.19 doesn't have such information. One possible
workaround is to check big enough 'dmesg' and look for cpu_sibling_map.
That tells you the mapping of logical processors to physical package. Or
you can have a init script like this (attached) in place, to run at boot
time, so that you have a better chance of finding these particular
messages in log (without overflowing).
HTH,
Venkatesh
-------------------
#!/bin/sh
# checkht kernel RC file.
#
# chkconfig: 35 98 98
# description: check for hyperthreaded CPUs
HASHT=`/bin/dmesg | /bin/grep cpu_sibling_map`
if [ -n "$HASHT" ]; then
/bin/echo "Machine is running HT"
/bin/echo 1 > /etc/hyperthreaded
else
/bin/echo "Machine isn't running HT"
/bin/echo 0 > /etc/hyperthreaded
Fi
--------------
> -----Original Message-----
> From: Jason Lunz [mailto:lunz@falooley.org]
> Sent: Thursday, January 09, 2003 12:03 PM
> To: linux-kernel@vger.kernel.org
> Subject: detecting hyperthreading in linux 2.4.19
>
>
> Is there a way for a userspace program running on linux 2.4.19 to tell
> the difference between a single hyperthreaded xeon P4 with HT enabled
> and a dual hyperthreaded xeon P4 with HT disabled? The /proc/cpuinfos
> for the two cases are indistinguishable.
>
> Jason
>
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: File perforation.
From: Bryan Henderson @ 2003-01-10 1:39 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-fsdevel, Steve Whitehouse
In-Reply-To: <23614.1042067811@passion.cambridge.redhat.com>
>Nothing else that fadvise() offers actually changes the file. They're all
>optional -- if the kernel ignores your fadvise()
Not only that, it's optional from the user's side too. You can can ignore
your own advice and do something else instead, and the kernel has to
produce the same result as if you hadn't advised at all.
^ permalink raw reply
* [Linux-ia64] Patches for Cleaning offsets.h/print_offsets.h/print_offsets.s
From: Yu, Fenghua @ 2003-01-10 1:38 UTC (permalink / raw)
To: linux-ia64
[-- Attachment #1: Type: text/plain, Size: 372 bytes --]
Hi,
2.5.52 and tpc.0.18 can't clean arch/ia64/tools/offsets.h, print_offsets.h,
print_offsets.s under arch/ia64/tools even with make
distclean/mrproper/clean. The feature is working for 2.4.20.
2.5.52 is supposed to clean the files by "make clean". Tpc.0.18 is supposed
to clean the files by "make mrproper". Thus, they have different fix
solutions.
Thanks.
-Fenghua
[-- Attachment #2: kernel-2.4.18-tpc.0.18-clean_offset.diff --]
[-- Type: text/plain, Size: 289 bytes --]
diff -Nur A/arch/ia64/tools/Makefile B/arch/ia64/tools/Makefile
--- A/arch/ia64/tools/Makefile Thu Jan 9 20:16:16 2003
+++ B/arch/ia64/tools/Makefile Thu Jan 9 20:16:58 2003
@@ -4,7 +4,7 @@
all:
-mrproper:
+mrproper: clean
clean:
rm -f print_offsets.s print_offsets offsets.h
[-- Attachment #3: linux-2.5.52-ia64-021221-clean_offset.diff --]
[-- Type: text/plain, Size: 849 bytes --]
diff -Nur A/arch/ia64/Makefile B/arch/ia64/Makefile
--- A/arch/ia64/Makefile Thu Jan 9 19:34:56 2003
+++ B/arch/ia64/Makefile Thu Jan 9 19:35:36 2003
@@ -61,6 +61,7 @@
archmrproper:
archclean:
$(Q)$(MAKE) -f scripts/Makefile.clean obj=arch/ia64/boot
+ $(Q)$(MAKE) -f scripts/Makefile.clean obj=arch/ia64/tools
CLEAN_FILES += include/asm-ia64/offsets.h vmlinux.gz bootloader
diff -Nur A/arch/ia64/tools/Makefile B/arch/ia64/tools/Makefile
--- A/arch/ia64/tools/Makefile Thu Jan 9 19:34:56 2003
+++ B/arch/ia64/tools/Makefile Thu Jan 9 19:35:36 2003
@@ -4,14 +4,7 @@
src = $(obj)
-all:
-
-fastdep:
-
-mrproper: clean
-
-clean:
- rm -f $(obj)/print_offsets.s $(obj)/print_offsets $(obj)/offsets.h
+clean-files := print_offsets.s print_offsets offsets.h
$(TARGET): $(obj)/offsets.h
@if ! cmp -s $(obj)/offsets.h ${TARGET}; then \
^ permalink raw reply
* SELF: compile of util-linux
From: James Don @ 2003-01-10 1:35 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I am just browsing through the SELF code ... and trying for kicks to make
"my own version" as an exercise to learn more about packages required for a
running embedded Linux system ...
So far I have ...
1.) Built uclibc
2.) Built busybox with uclibc gcc wrappers
3.) Built insmod with uclibc gcc wrappers
I am reading the compile of util-linux (see below item 1) ... I am
relatively new to linux so I have some questions (most of which are probably
stupid seeing as just started looking at this)...
1.) The "patch" part of the compile ... is it to add kernel support for what
I am compiling? If I managed to get a pre-built image to run on an unpatched
kernel what am I missing?
2.) When you run the "sed -e 's/XXX-powerpc-linux-/$(CROSS_PREFIX)/" I
assume this should go into the make sysyem and put the cross compiler in the
build ? ... sorry never used "sed" just skimmed the man page
3.) For kicks I have taken the tar ball I downloaded of util-linux (version
2.11y) and tried to compile it with the uclibc gcc wrappers (see item 2
below) ... now this does when I get to the "make part" ... it seems to die
because "configure" was not called ... but its not called from SELF's make
file either ??? If I call make from the util-linux directory it calls
configure ... but then uses my local 'cc' ...
Any tips would be great ;-) In the mean time I will keep digging and
hopefully see what's wrong with my script ;-)
Best regards,
Jim
item 1
============
$(LOGIN)/login-utils/login: $(LOGIN)/.patch
$(MAKE) -C $(LOGIN)/lib
$(MAKE) -C $(LOGIN)/login-utils login
$(LOGIN)/.patch: $(CONFIGURATION) \
$(TARBALLS)/util-linux-$(LOGIN_VERSION).tar.gz \
$(PATCHES)/util-linux-$(LOGIN_VERSION)-cross.$(P_SUFF) \
$(PATCHES)/util-linux-$(LOGIN_VERSION)-nosetproctitle.$(P_SUFF) \
$(CONFIG)/config.mk
rm -fr $(LOGIN)
cd $(BUILD) && \
gzip -cd $(TARBALLS)/util-linux-$(LOGIN_VERSION).tar.gz | tar xf -
cd $(LOGIN) && \
sed -e 's/XXX-powerpc-linux-/$(CROSS_PREFIX)/' \
$(PATCHES)/util-linux-$(LOGIN_VERSION)-cross.$(P_SUFF) | \
patch -p1 -b -z.cross && \
patch -p1 -b -z.no_sp
<$(PATCHES)/util-linux-$(LOGIN_VERSION)-nosetproctitle.$(P_SUFF) && \
touch .patch
item 2
==============
#!/usr/bin/bash
LOGIN_UTIL_VERSION=2.11y
LOGIN_BUILD_DIR=$HOME/ppcLoginUtil/
CROSS=powerper-uclibc-
echo LOGIN_BUILD_DIR=$LOGIN_BUILD_DIR
rm -fr $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION
tar xvfz $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION.tar.gz
cd $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION
sed -e 's/XXX-powerpc-linux-/$CROSS/' *
make -C $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION/lib
make -C $LOGIN_BUILD_DIR/util-linux-$LOGIN_UTIL_VERSION/login-utils login
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [linux-lvm] Re: LVM Recovery - mostly solved
From: Andre Bonhote @ 2003-01-10 1:35 UTC (permalink / raw)
To: Linux-LVM; +Cc: mauelshagen, beat
In-Reply-To: <EHEDIKGDCNFCNANFPGCDAENOCAAA.andre@bonhote.com>
Good morning!
Well, this is quite embarassing to me. Bear with me please.
On Wed, Jan 08, 2003 at 03:35:35PM +0100, Andre Bonhote wrote:
...
> - 1 IDE drive, 80 GB
...
> /dev/hdc
> fdisk -l shows no output. There's no partitioning. I did pvcreate /dev/hdc.
Here we go! That's the point. fdisk -l shows no output because there's
no disk. Between the (doubtless incredibly dumb, but harmless) changes
and the reboot, I have tried to find a place for a spare harddrive in my
chassis. Doing that, the one and only IDE cable loosened. Result:
/dev/hdc was gone.
My focus at that time was of course elsewhere. I always have disabled
IDE scanning in the BIOS, otherwise I would have noticed it immediately
- the system hangs in the BIOS. Linux just says: There's no IDE drive.
And Linux is right.
> mount: error 2 mounting ext3
> pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2
> umount /initrd/proc failed: 2
This comes clear to me now, too. I have to change Grub and/or the
initrd, I guess. I will take a closer look at this this WE.
> no (which?) config files have been updated. Could this be a bug?
Of course NOT!
> ...
> reading data of volume group "CaradhrasVG" from physical volume(s)
> ERROR "vg_read_with_pv_and_lv(): current PV" can't get data of volume
> group "CaradhrasVG" from physical volumes
> ...
It was trying to read /dev/hdc, but it didn't succeed. How should it?
Well, anyway. I managed to pull down the important data.
List readers/posters: A double sorry to you for wasting your precious
bandwith and for holding you up. I am going to read ALL the docs I can
find on sistina.com about backing up metadata, I promise. And I will
think more than twice next time before posting to this list, and have a
loooong nap before, too.
Thanks to all & a really nice day!
Andr�
--
Real programmers do "cp /dev/audio a.out" and whistle into the mike.
(Randal L. Schwartz)
^ permalink raw reply
* Re: File perforation.
From: Bryan Henderson @ 2003-01-10 1:34 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-fsdevel
In-Reply-To: <21551.1042063560@passion.cambridge.redhat.com>
On AIX, that's the clear() system call. It's defined to be identical to
write() except that it always writes zeroes. It is up to the individual
filesystem driver whether it implements it by punching holes in files or
not.
I've implemented this on a block filesystem type, and the only hairy part
about it is taking care of the sub-block fringes of the range being
written -- complicated by the fact that the write may go past end of file.
In practice, this system call gets used only when the caller knows that it
creates a hole and knows the block size and thus does a clear only of
whole blocks. Basically, we're talking database managers.
--
Bryan Henderson IBM Research
San Jose CA Filesystems
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: Andrew McGregor @ 2003-01-10 1:34 UTC (permalink / raw)
To: Valdis.Kletnieks, jlnance; +Cc: linux-kernel
In-Reply-To: <200301092030.h09KUspQ009950@turing-police.cc.vt.edu>
--On Thursday, January 09, 2003 15:30:54 -0500 Valdis.Kletnieks@vt.edu
wrote:
> On Thu, 09 Jan 2003 15:21:44 EST, jlnance@unity.ncsu.edu said:
>> On Thu, Jan 09, 2003 at 12:40:19PM -0700, Val Henson wrote:
>>
>> > P.S. For extra credit (but no ThinkGeek certificate) you can look up
>> > the following women in computer science, some of whom are mothers:
>> > Mary Baker, Margo Seltzer, Monica Lam, Ellen Spertus, Carla Ellis, and
>> > Barbara Simons.
>>
>> Am I the first person to tell you you left off Ada Lovelace? She was
>> way ahead of her time.
>
> I think Ada Lovelace and Grace Hopper were left off as "too easy"....
Sally Floyd and Allison Mankin?
^ permalink raw reply
* Re: access memory mapped registers
From: Wolfgang Denk @ 2003-01-10 1:20 UTC (permalink / raw)
To: Muaddi, Cecilia; +Cc: linuxppc-embedded
In-Reply-To: <885489B3B89FB6449F93E525DF78777F064542@srvnt506.ALLOPTIC.COM>
In message <885489B3B89FB6449F93E525DF78777F064542@srvnt506.ALLOPTIC.COM> you wrote:
>
> I can see if I mmap the internal 860 CPU registers, and screw up that, I
> will
> definitely screw up the system, and require it to be reboot. BUt if the
> hardware we are mapping is outside the CPU internal memory and outside the
> RAM,
> shouldn't the failure be limited to the user application only then?
No. For example, assume there is a port pin which is meant as an
input, and the signal is driven from external hardware. Now your
application program by mistake re-programs this pin as output. You
may smoke your board this way.
> only the memory regions that is mapped to the ethernet switching chip,
> even if I screw up on the hardware setup, shouldn't my kernel still be
> protected? At most, the application faults and I should be able to restart
> the application without rebooting the system?
There is a simple rule: if you open backdoors in a secure system the
result is an insecure system. Write clean code.
There is many things you have to keep in mind:
* Functionality: you cannot process interrupts in user space
* Performance: how do you synchronize your accesses to the hardware?
* Communication: How do you know when data has been processed, or has
become available, or stable, or ...?
* Tricky things: What will the caches in your system do when the
application accesses the hardware? How will you address memory?
Remember that there are systems where a 32 bit address is not
sufficient any more...
etc. etc.
Write clean code.
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
Life is a game. Money is how we keep score. - Ted Turner
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: Chris Adams @ 2003-01-10 1:24 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1042153890.28469.21.camel@irongate.swansea.linux.org.uk>
Once upon a time, Alan Cox <alan@lxorguk.ukuu.org.uk> said:
>and of course Sally Floyd, and even Hedy Lamarr (bonus points for those
>who know what her networking related patent is on)
That's HEDLEY! Oh, but he doesn't have any patents.
--
Chris Adams <cmadams@hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
^ permalink raw reply
* Re: access memory mapped registers
From: Wolfgang Denk @ 2003-01-10 1:12 UTC (permalink / raw)
To: Muaddi, Cecilia; +Cc: 'linuxppc-embedded@lists.linuxppc.org'
In-Reply-To: <885489B3B89FB6449F93E525DF78777F064541@srvnt506.ALLOPTIC.COM>
In message <885489B3B89FB6449F93E525DF78777F064541@srvnt506.ALLOPTIC.COM> you wrote:
>
> Given that, do you know what is the convention if I need to address the GPIO
> pins in
> the 860? I have some FPGA which require me to download the FPGA code
> and they are controlled via JTAG from my GPIO pins out of 860. I can use
> mmap to map the ppc 860 internal memory (the quick dirty way just to see if
> works), or is there a driver already provided which will allow me to control
> the GPIO pins from user application?
There is no such driver, and there cannot be any such generic driver,
as the usage of the port pins is different for each board. And it
would be a very bad idea to allow any user to mess with important
things. You can even ruin hardware that way.
Do yourself a favour and write a device driver that does what needs
to be done.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
There is nothing in this world constant but inconstancy. - Swift
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: ipv6 stack seems to forget to send ACKs
From: Andrew McGregor @ 2003-01-10 1:17 UTC (permalink / raw)
To: Wichert Akkerman, netdev, linux-kernel
In-Reply-To: <20030109155214.GX22951@wiggy.net>
--On Thursday, January 09, 2003 16:52:14 +0100 Wichert Akkerman
<wichert@wiggy.net> wrote:
> Previously Rogier Wolff wrote:
>> Can you check the stats counters, to see if they are indeed dropped?
>
> It seems no packets are dropped:
>
...
> Tcp:
> 666 active connections openings
> 0 passive connection openings
> 0 failed connection attempts
> 0 connection resets received
> 2 connections established
> 58949 segments received
> 65043 segments send out
> 0 segments retransmited
> 18 bad segments received.
Is this it? My counters show zero, in vastly more packets.
Andrew
^ permalink raw reply
* Pushing a stray sk_buff to the NIC
From: Joshua Stewart @ 2003-01-10 1:10 UTC (permalink / raw)
To: Linux Kernel Mailing List, Linux network development
I'm trying to take "hand-built" sk_buffs with little more than some data
and a dev member and push them to the NIC for transmission. I would
like to simply give them to dev_queue_xmit. Does anybody know what
state I should have them in before handing them to dev_queue_xmit?
Should skb->data point to the start of a MAC header or an IP header?
Also, given an IP address in skb->nh.iph->daddr, what's the easiest way
to get the appropriate MAC address?
J
^ permalink raw reply
* Re: [patch 2.5] 2-pass PCI probing, generic part
From: Grant Grundler @ 2003-01-10 1:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ivan Kokshaysky, Benjamin Herrenschmidt, Alan Cox, Paul Mackerras,
Eric W. Biederman, davidm, Linux Kernel Mailing List, greg
In-Reply-To: <Pine.LNX.4.44.0301091531260.1506-100000@penguin.transmeta.com>
On Thu, Jan 09, 2003 at 03:35:32PM -0800, Linus Torvalds wrote:
> The only real reason to worry about BAR sizing is really to do resource
> discovery in order to make sure that out bridges have sufficiently big
> windows for the IO regions. Agreed?
yes. And eventually to make sure regions don't overlap.
> And that should be a non-issue especially on a host bridge, since we
> almost certainly don't want to reprogram the bridge windows there anyway.
Current PARISC servers do not allocate MMIO/IO resources for all PCI devices.
Only boot devices are configured. Fortunately, default MMIO/IO address
space assigned to Host bridges seems to work - at least I've not heard
anyone complain (yet). But no one has tried PCI expansion chassis or
cards with massive (> 64MB) MMIO BARs.
Because of PCI hotplug, rumor is ia64 firmware folks want to do
the same thing in the near future.
> So I'd like to make the _default_ be to probe the minimal possible,
> _especially_ for host bridges. Then, the PCI quirks could be used to
> expand on that default.
That's reasonable.
pci arch code also has hooks to fixup host bridge resources.
thanks,
grant
^ permalink raw reply
* 405LP PCMCIA cleanup
From: David Gibson @ 2003-01-10 0:55 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Todd Poynor, Ken Inoue
The patch below makes some cleanups to the handling of the PCMCIA
interface on the 405LP. In particular, it removes the need for a
hardcoded io_block_mapping() in the board setup code, replacing it
with ioremap()s.
Unfortunately, the ioremap()s can't live in the pccf_4xx driver
itself, since this would lead to _IO_BASE and ISA_MEM_BASE being
initialized far too late. So instead, I use the hack of an
ibm405lp_setup_pccf() function provided in ibm405lp.c, to be used by
the board setup code.
This is tested on Arctic-II, but not on Beech. If there aren't
serious objections, I'll commit it to linuxppc_2_4_devel.
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/kernel/ppc_ksyms.c linux-bartholomew/arch/ppc/kernel/ppc_ksyms.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/kernel/ppc_ksyms.c 2003-01-07 22:00:10.000000000 +1100
+++ linux-bartholomew/arch/ppc/kernel/ppc_ksyms.c 2003-01-09 16:16:33.000000000 +1100
@@ -175,7 +175,7 @@
EXPORT_SYMBOL(ppc_ide_md);
#endif
-#if defined(CONFIG_PCI) || defined(CONFIG_BEECH)
+#if defined(CONFIG_PCI)
EXPORT_SYMBOL_NOVERS(isa_io_base);
EXPORT_SYMBOL_NOVERS(isa_mem_base);
#endif
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/Makefile linux-bartholomew/arch/ppc/platforms/Makefile
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/Makefile 2002-12-20 15:23:32.000000000 +1100
+++ linux-bartholomew/arch/ppc/platforms/Makefile 2003-01-08 17:00:39.000000000 +1100
@@ -24,7 +24,7 @@
O_TARGET := platform.o
-export-objs := prep_setup.o beech.o ibm405lp.o
+export-objs := prep_setup.o beech.o ibm405lp.o arctic2.o
obj-$(CONFIG_CEDER) += ceder.o ibmnp405l.o
obj-$(CONFIG_CPCI405) += cpci405.o ibm405gp.o
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.c linux-bartholomew/arch/ppc/platforms/arctic2.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.c 2002-12-16 12:59:59.000000000 +1100
+++ linux-bartholomew/arch/ppc/platforms/arctic2.c 2003-01-09 17:14:48.000000000 +1100
@@ -47,6 +47,15 @@
#include <platforms/arctic2.h>
+/* Virtual address of the PCCF macro, which needs to be ioremap()ed
+ * and initialized by the board setup code. */
+volatile u16 *pccf_4xx_macro_vaddr;
+unsigned long pccf_4xx_io_base;
+unsigned long pccf_4xx_mem_base;
+EXPORT_SYMBOL(pccf_4xx_macro_vaddr);
+EXPORT_SYMBOL(pccf_4xx_io_base);
+EXPORT_SYMBOL(pccf_4xx_mem_base);
+
void __init
board_setup_arch(void)
{
@@ -63,8 +72,8 @@
ARCTIC2_FPGA8_SIZE, _PAGE_IO);
io_block_mapping(ARCTIC2_FPGA16_VADDR, ARCTIC2_FPGA16_PADDR,
ARCTIC2_FPGA16_SIZE, _PAGE_IO);
- io_block_mapping(SUBZERO_BEECH_PCMCIA_VADDR, SUBZERO_BEECH_PCMCIA_PADDR,
- SUBZERO_BEECH_PCMCIA_SIZE, _PAGE_IO);
+ ibm405lp_setup_pccf(&pccf_4xx_macro_vaddr, &pccf_4xx_io_base,
+ &pccf_4xx_mem_base);
}
void __init
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.h linux-bartholomew/arch/ppc/platforms/arctic2.h
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.h 2002-12-18 11:53:11.000000000 +1100
+++ linux-bartholomew/arch/ppc/platforms/arctic2.h 2003-01-09 16:19:10.000000000 +1100
@@ -60,6 +60,10 @@
#define PPC4xx_MACHINE_NAME "IBM Arctic II"
+#include <asm/pccf_4xx.h>
+#define _IO_BASE (pccf_4xx_io_base)
+#define _ISA_MEM_BASE (pccf_4xx_mem_base)
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_ARCTIC2_H__ */
#endif /* __KERNEL__ */
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/beech.c linux-bartholomew/arch/ppc/platforms/beech.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/beech.c 2003-01-01 22:47:20.000000000 +1100
+++ linux-bartholomew/arch/ppc/platforms/beech.c 2003-01-09 17:14:58.000000000 +1100
@@ -45,8 +45,6 @@
static void beech_ebc_setup(void);
static void beech_fpga_setup(void);
-unsigned long isa_io_base;
-unsigned long isa_mem_base;
volatile u8 *beech_fpga_reg_0 = NULL;
volatile u8 *beech_fpga_reg_2 = NULL;
volatile u8 *beech_fpga_reg_4 = NULL;
@@ -55,6 +53,15 @@
EXPORT_SYMBOL(beech_fpga_reg_2);
EXPORT_SYMBOL(beech_fpga_reg_4);
+/* Virtual address of the PCCF macro, which needs to be ioremap()ed
+ * and initialized by the board setup code. */
+volatile u16 *pccf_4xx_macro_vaddr;
+unsigned long pccf_4xx_io_base;
+unsigned long pccf_4xx_mem_base;
+EXPORT_SYMBOL(pccf_4xx_macro_vaddr);
+EXPORT_SYMBOL(pccf_4xx_io_base);
+EXPORT_SYMBOL(pccf_4xx_mem_base);
+
/*
Beech board physical memory map:
@@ -119,6 +126,8 @@
void __init
board_io_mapping(void)
{
+ ibm405lp_setup_pccf(&pccf_4xx_macro_vaddr, &pccf_4xx_io_base,
+ &pccf_4xx_mem_base);
}
void __init
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/beech.h linux-bartholomew/arch/ppc/platforms/beech.h
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/beech.h 2002-12-18 11:53:11.000000000 +1100
+++ linux-bartholomew/arch/ppc/platforms/beech.h 2003-01-09 16:15:43.000000000 +1100
@@ -166,13 +166,6 @@
#define BEECH_FREE_AREA_OFFSET BEECH_KERNEL_SIZE
#define BEECH_FREE_AREA_SIZE (BEECH_BIGFLASH_SIZE - BEECH_KERNEL_SIZE)
-/* The PCMCIA controller driver 4xx_pccf.c is responsible for the EBC setup of
- PCMCIA. Externally, EBC bank selects 3..7 take on PCMCIA functions when
- PCMCIA is enabled. */
-
-#define BEECH_PCMCIA_PADDR ((uint)0xf0000000)
-#define BEECH_PCMCIA_SIZE ((uint)(32 * 1024 * 1024))
-
/* We do not currently support the internal clock mode for the UART. This
limits the minimum OPB frequency to just over 2X the UART oscillator
frequency. At OPB frequencies less than this the serial port will not
@@ -185,12 +178,12 @@
#define PPC4xx_MACHINE_NAME "IBM 405LP Beech"
-#define _IO_BASE isa_io_base
-#define _ISA_MEM_BASE isa_mem_base
-#define PCI_DRAM_OFFSET 0
+#define PCI_DRAM_OFFSET 0
+
+#include <asm/pccf_4xx.h>
+#define _IO_BASE (pccf_4xx_io_base)
+#define _ISA_MEM_BASE (pccf_4xx_mem_base)
-extern unsigned long isa_io_base;
-extern unsigned long isa_mem_base;
/****************************************************************************
* Non-standard board support follows
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/ibm405lp.c linux-bartholomew/arch/ppc/platforms/ibm405lp.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/ibm405lp.c 2003-01-01 22:47:20.000000000 +1100
+++ linux-bartholomew/arch/ppc/platforms/ibm405lp.c 2003-01-09 17:29:42.000000000 +1100
@@ -43,6 +43,7 @@
#include <asm/time.h>
#include <asm/uaccess.h>
#include <asm/ocp.h>
+#include <asm/pccf_4xx.h>
struct ocp_def core_ocp[] = {
{UART, UART0_IO_BASE, UART0_INT},
@@ -266,6 +267,109 @@
}
}
+/* Somewhat misleading name, as well as the EBC, this sets up the UIC
+ and CPC ready for PCMCIA operation */
+static void
+pccf_ebc_setup(void)
+{
+ /* Set up EBC bank 4 as per PCCF docs., assuming 66 MHz EBC bus. The
+ ready timeout is set for 1024 cycles (~ 15 us at 66 MHz), unless
+ someone else has already set it for 2048. In the event of a
+ timeout we'll get a Data Machine Check. */
+
+ unsigned long bits, mask, flags;
+
+ save_flags(flags);
+ cli();
+
+ /* Program EBC0_CFG for ready timeout */
+
+ mtdcr(DCRN_EBC0_CFGADDR, DCRN_EBC0_CFG);
+ bits = mfdcr(DCRN_EBC0_CFGDATA);
+ if ((bits & EBC_CFG_RTC) != EBC_CFG_RTC_2048)
+ mtdcr(DCRN_EBC0_CFGDATA, (bits & ~EBC_CFG_RTC) | EBC_CFG_RTC_1024);
+
+ /* Program EBC bank properties : 32 MB, 16-bit RW bank;
+ BME = 0, TWT = 22, CSN = 2, OEN = 3, WBN = WBF = 0, TH = 5,
+ RE = 1, SOR = 0, BEM = 1 */
+
+ mtdcr(DCRN_EBC0_CFGADDR, DCRN_EBC0_B4CR);
+ mtdcr(DCRN_EBC0_CFGDATA, (PCCF_4XX_PADDR & 0xfff00000) | 0x000ba000);
+ mtdcr(DCRN_EBC0_CFGADDR, DCRN_EBC0_B4AP);
+ mtdcr(DCRN_EBC0_CFGDATA, 0x0b0b0b40);
+
+ /* Program the UIC for active-high, level-triggered interrupts. Note
+ that the active-low PCMCIA interrupt pin is inverted by the PCCF
+ macro. */
+
+ mask = (0x80000000 >> PCCF_4XX_MACRO_IRQ) |
+ (0x80000000 >> PCCF_4XX_CARD_IRQ);
+
+ bits = mfdcr(DCRN_UIC0_PR);
+ bits |= mask;
+ mtdcr(DCRN_UIC0_PR, bits);
+
+ bits = mfdcr(DCRN_UIC0_TR);
+ bits &= ~mask;
+ mtdcr(DCRN_UIC0_TR, bits);
+
+ /* Clear CPC0_CR0[PCMD] to enable the PCMCIA controller */
+
+ mtdcr(DCRN_CPC0_CR0, mfdcr(DCRN_CPC0_CR0) & ~0x00000200);
+
+ restore_flags(flags);
+}
+
+/* Map the PCCF controller's memory windows.
+ *
+ * HACK ALERT: Logically this belongs in the pccf_4xx driver itself,
+ * however that causes problems because it happens so late in
+ * initialization. We want to use some ISA-ish drivers (notably
+ * 8390.c) on memory mapped devices by using the
+ * ioaddr=(memaddr-_IO_BASE) hack. If _IO_BASE is the PCMCIA ISA IO
+ * space (which we want so PC Card drivers using ISA IO work) but is
+ * not initialized until the pccf_4xx driver starts, this could well
+ * be after drivers like 8390 have initialized and computed a fake
+ * "IO" address which is now incorrect. Putting the ioremap()ing of
+ * the PCCF macro in the chip/board setup code works around this
+ * problem. */
+int
+ibm405lp_setup_pccf(volatile u16 **vaddr, unsigned long *io_base,
+ unsigned long *mem_base)
+{
+ pccf_ebc_setup();
+
+ *vaddr = ioremap(PCCF_4XX_MACRO_PADDR, PCCF_4XX_MACRO_WINSIZE);
+
+ if (*vaddr == NULL) {
+ printk(KERN_ERR "pccf_4xx: ioremap macro at 0x%lx failed.\n",
+ PCCF_4XX_MACRO_PADDR);
+ return -EBUSY;
+ }
+
+ printk("ibm405lp_setup_pcmcia: phys addr = %lx, virt addr = %p\n",
+ PCCF_4XX_MACRO_PADDR, *vaddr);
+
+ *io_base = (unsigned long) ioremap(PCCF_4XX_IO_PADDR,
+ PCCF_4XX_IO_WINSIZE);
+ if (*io_base == 0) {
+ printk(KERN_ERR "pccf_4xx: ioremap io at 0x%lx failed.\n",
+ PCCF_4XX_IO_PADDR);
+ return -EBUSY;
+ }
+
+ *mem_base = (unsigned long) ioremap(PCCF_4XX_MEM_PADDR,
+ PCCF_4XX_MEM_WINSIZE);
+ if (*mem_base == 0) {
+ printk(KERN_ERR "pccf_4xx: ioremap mem at 0x%lx failed.\n",
+ PCCF_4XX_MEM_PADDR);
+ return -EBUSY;
+ }
+
+ return 0;
+}
+
+
/****************************************************************************
* TODC
****************************************************************************/
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/ibm405lp.h linux-bartholomew/arch/ppc/platforms/ibm405lp.h
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/ibm405lp.h 2002-12-18 11:53:11.000000000 +1100
+++ linux-bartholomew/arch/ppc/platforms/ibm405lp.h 2003-01-09 17:55:53.000000000 +1100
@@ -316,6 +316,16 @@
#define TDES0_IO_BASE 0xef600b00
+/* The PCMCIA controller driver 4xx_pccf.c is responsible for the EBC setup of
+ PCMCIA. Externally, EBC bank selects 3..7 take on PCMCIA functions when
+ PCMCIA is enabled. */
+
+#define PCCF_4XX_PADDR (0xf0000000UL)
+#define PCCF_4XX_SIZE (32 * 1024 * 1024)
+#define PCCF_4XX_MACRO_IRQ UIC_IRQ_EIR5
+#define PCCF_4XX_CARD_IRQ UIC_IRQ_EIR6
+
+
/*****************************************************************************
* CPM bits for the 405LP. Field names are as documented in the 405LP manual.
* Backwards-compatible synonyms appear at the end.
@@ -901,6 +911,8 @@
****************************************************************************/
int ibm405lp_set_pixclk(unsigned pixclk_min, unsigned pixclk_max);
+int ibm405lp_setup_pccf(volatile u16 **vaddr, unsigned long *io_base,
+ unsigned long *mem_base);
void ibm405lp_reset_sdram(u32 new_rtr, u32 new_tr);
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.h linux-bartholomew/arch/ppc/platforms/subzero.h
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.h 2002-12-16 13:00:04.000000000 +1100
+++ linux-bartholomew/arch/ppc/platforms/subzero.h 2003-01-09 16:19:20.000000000 +1100
@@ -88,21 +88,7 @@
#define SUBZERO_BOOTFLASH_PADDR (SUBZERO_BANK0_PADDR)
#define SUBZERO_BOOTFLASH_SIZE ((uint)(32 * 1024 * 1024))
-/* The PCMCIA controller driver 4xx_pccf.c is responsible for the EBC setup of
- PCMCIA. Externally, EBC bank selects 3..7 take on PCMCIA functions when
- PCMCIA is enabled. */
-
-#define SUBZERO_BEECH_PCMCIA_PADDR ((uint)0xf0000000)
-#define SUBZERO_BEECH_PCMCIA_VADDR SUBZERO_BEECH_PCMCIA_PADDR
-#define SUBZERO_BEECH_PCMCIA_SIZE ((uint)(32 * 1024 * 1024))
-
-#define SUBZERO_BEECH_PCMCIA_IO_BASE (SUBZERO_BEECH_PCMCIA_VADDR + 0x01800000)
-
-/* Define _IO_BASE for PCMCIA; other defines are required as well. */
-
-#define _IO_BASE SUBZERO_BEECH_PCMCIA_IO_BASE
-#define _ISA_MEM_BASE 0
-#define PCI_DRAM_OFFSET 0
+#define PCI_DRAM_OFFSET 0
void *beech_sram_alloc(size_t size);
int beech_sram_free(void *p);
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/pcmcia/Config.in linux-bartholomew/drivers/pcmcia/Config.in
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/pcmcia/Config.in 2002-08-14 09:23:45.000000000 +1000
+++ linux-bartholomew/drivers/pcmcia/Config.in 2002-12-19 15:21:01.000000000 +1100
@@ -29,7 +29,7 @@
if [ "$CONFIG_8xx" = "y" ]; then
dep_tristate ' M8xx support' CONFIG_PCMCIA_M8XX $CONFIG_PCMCIA
fi
- if [ "$CONFIG_BEECH" = "y" ]; then
+ if [ "$CONFIG_405LP" = "y" ]; then
dep_tristate ' IBM 4xx PCCF support' CONFIG_PCMCIA_PCCF_4xx $CONFIG_PCMCIA
fi
fi
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/drivers/pcmcia/pccf_4xx.c linux-bartholomew/drivers/pcmcia/pccf_4xx.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/drivers/pcmcia/pccf_4xx.c 2002-08-14 09:23:45.000000000 +1000
+++ linux-bartholomew/drivers/pcmcia/pccf_4xx.c 2003-01-09 17:38:07.000000000 +1100
@@ -236,6 +236,7 @@
#include <pcmcia/bus_ops.h>
#include <asm/byteorder.h>
+#include <asm/pccf_4xx.h>
MODULE_AUTHOR("Eric Van Hensbergen <bergevan@us.ibm.com>");
MODULE_DESCRIPTION("IBM PCCF 4xx socket driver");
@@ -250,6 +251,8 @@
static const char *version =
"pccf_4xx.c $Revision: 1.3 $ $Date: 2001/10/26 02:22:41 $ (Eric Van Hensbergen)";
+#define PCMCIA_DEBUG 0
+
#ifdef PCMCIA_DEBUG
static int pc_debug = PCMCIA_DEBUG;
MODULE_PARM(pc_debug, "i");
@@ -262,44 +265,20 @@
/* Configurations */
-#define PCMCIA_PADDR BEECH_PCMCIA_PADDR
-#define MACRO_IRQ UIC_IRQ_EIR5
-#define CARD_IRQ UIC_IRQ_EIR6
#define VCC5V_SUPPORT 1
/* Minimum bus cycle time (in ns) */
#define MIN_SPEED 300
-/* Areas that we ioremap() are mapped only as large as necessary to get the job
- done: Only a few locations of the macro space are used, and legacy IO space
- is only 64 KB. There is 1 memory window, and 2 virtual IO windows. */
-
-#define PCMCIA_MEM_WIN_SIZE (8*1024*1024)
-
-#define PCMCIA_MACRO_OFFSET 0x00000000
-#define PCMCIA_MACRO_PADDR (PCMCIA_PADDR + PCMCIA_MACRO_OFFSET)
-#define PCMCIA_MACRO_WINSIZE PAGE_SIZE
-
-#define PCMCIA_ATTRIB_OFFSET 0x00800000
-#define PCMCIA_ATTRIB_PADDR (PCMCIA_PADDR + PCMCIA_ATTRIB_OFFSET)
-#define PCMCIA_ATTRIB_WINSIZE PCMCIA_MEM_WIN_SIZE
-
-#define PCMCIA_MEM_OFFSET 0x01000000
-#define PCMCIA_MEM_PADDR (PCMCIA_PADDR + PCMCIA_MEM_OFFSET)
-#define PCMCIA_MEM_WINSIZE PCMCIA_MEM_WIN_SIZE
-
-#define PCMCIA_IO_OFFSET 0x01800000
-#define PCMCIA_IO_PADDR (PCMCIA_PADDR + PCMCIA_IO_OFFSET)
-#define PCMCIA_IO_WINSIZE 0x00010000
+#define PCMCIA_ATTRIB_OFFSET 0x00800000
+#define PCMCIA_ATTRIB_PADDR (PCCF_4XX_PADDR + PCMCIA_ATTRIB_OFFSET)
#define PCMCIA_MEM_WIN_NO 1
#define PCMCIA_IO_WIN_NO 2
-volatile unsigned short *pcmcia_macro_vaddr = NULL;
-
#define PCMCIA_CTRL(offset)\
- ((volatile unsigned short *)((u8 *) pcmcia_macro_vaddr + (offset)))
+ ((volatile unsigned short *)((u8 *) pccf_4xx_macro_vaddr + (offset)))
/* PCCF control registers are big-endian */
@@ -578,7 +557,7 @@
0, /* No ISA interrupts */
PAGE_SIZE, /* Window size granularity */
0, /* io_offset */
- CARD_IRQ, /* Single fixed socket interrupt */
+ PCCF_4XX_CARD_IRQ, /* Single fixed socket interrupt */
NULL, /* No CardBus support */
NULL /* No virtual bus operations */
};
@@ -593,60 +572,6 @@
Configuration-specific code
****************************************************************************/
-static void
-ebc_setup(void)
-{
- /* Set up EBC bank 4 as per PCCF docs., assuming 66 MHz EBC bus. The
- ready timeout is set for 1024 cycles (~ 15 us at 66 MHz), unless
- someone else has already set it for 2048. In the event of a
- timeout we'll get a Data Machine Check. */
-
- unsigned long bits, mask, flags;
-
- save_flags(flags);
- cli();
-
- /* Program EBC0_CFG for ready timeout */
-
- mtdcr(DCRN_EBC0_CFGADDR, DCRN_EBC0_CFG);
- bits = mfdcr(DCRN_EBC0_CFGDATA);
- if (get_field32(bits, 2, 4) != 7)
- mtdcr(DCRN_EBC0_CFGDATA, set_field32(bits, 2, 4, 6));
-
- /* Program EBC bank properties : 32 MB, 16-bit RW bank;
- BME = 0, TWT = 22, CSN = 2, OEN = 3, WBN = WBF = 0, TH = 5,
- RE = 1, SOR = 0, BEM = 1 */
-
- mtdcr(DCRN_EBC0_CFGADDR, DCRN_EBC0_B4CR);
- mtdcr(DCRN_EBC0_CFGDATA, (PCMCIA_PADDR & 0xfff00000) | 0x000ba000);
- mtdcr(DCRN_EBC0_CFGADDR, DCRN_EBC0_B4AP);
- mtdcr(DCRN_EBC0_CFGDATA, 0x0b0b0b40);
-
- /* Program the UIC for active-high, level-triggered interrupts. Note
- that the active-low PCMCIA interrupt pin is inverted by the PCCF
- macro. */
-
- mask = (0x80000000 >> MACRO_IRQ) | (0x80000000 >> CARD_IRQ);
-
- bits = mfdcr(DCRN_UIC0_PR);
- bits |= mask;
- mtdcr(DCRN_UIC0_PR, bits);
-
- bits = mfdcr(DCRN_UIC0_TR);
- bits &= ~mask;
- mtdcr(DCRN_UIC0_TR, bits);
-
-#if defined(CONFIG_405LP)
-
- /* Clear CPC0_CR0[PCMD] to enable the PCMCIA controller */
-
- mtdcr(DCRN_CPC0_CR0, mfdcr(DCRN_CPC0_CR0) & ~0x00000200);
-
-#endif /* CONFIG_405LP */
-
- restore_flags(flags);
-}
-
/* Voltage control. See comments at the beginning of the file.
The 'poweroff' situation is called out separately because we also use the
@@ -1036,10 +961,10 @@
if (state->flags & SS_IOCARD) {
pcmcia_io();
- if (state->io_irq && (state->io_irq != CARD_IRQ)) {
+ if (state->io_irq && (state->io_irq != PCCF_4XX_CARD_IRQ)) {
printk(KERN_CRIT "pccf_4xx: io_irq requested as %d, "
"should be %d. Aborting.\n",
- state->io_irq, CARD_IRQ);
+ state->io_irq, PCCF_4XX_CARD_IRQ);
return -EINVAL;
}
} else {
@@ -1114,8 +1039,8 @@
map = io->map;
if ((io->map >= PCMCIA_IO_WIN_NO) ||
- (io->start >= PCMCIA_IO_WINSIZE) ||
- (io->stop >= PCMCIA_IO_WINSIZE) || (io->stop < io->start)) {
+ (io->start >= PCCF_4XX_IO_WINSIZE) ||
+ (io->stop >= PCCF_4XX_IO_WINSIZE) || (io->stop < io->start)) {
printk(KERN_ERR "pccf_4xx: set_io_map: Illegal "
"IO map: map = %d, start = 0x%08x, stop = 0x%08x\n",
io->map, io->start, io->stop);
@@ -1197,9 +1122,9 @@
if ((mem->map >= PCMCIA_MEM_WIN_NO) ||
(mem->sys_start > mem->sys_stop) ||
- ((mem->sys_stop - mem->sys_start) >= PCMCIA_MEM_WINSIZE) ||
+ ((mem->sys_stop - mem->sys_start) >= PCCF_4XX_MEM_WINSIZE) ||
((mem->card_start + (mem->sys_stop - mem->sys_start)) >=
- PCMCIA_MEM_WINSIZE)) {
+ PCCF_4XX_MEM_WINSIZE)) {
DEBUG(4, "pccf_4xx: set_mem_map: Illegal "
"memory map: map = %d, start = 0x%08lx, stop = 0x%08lx "
"card_start = 0x%08x\n",
@@ -1217,7 +1142,7 @@
if (mem->flags & MAP_ATTRIB)
mem->sys_start = PCMCIA_ATTRIB_PADDR + mem->card_start;
else
- mem->sys_start = PCMCIA_MEM_PADDR + mem->card_start;
+ mem->sys_start = PCCF_4XX_MEM_PADDR + mem->card_start;
mem->sys_stop += mem->sys_start;
}
@@ -1311,35 +1236,9 @@
printk(KERN_INFO "%s\n", version);
- pcmcia_macro_vaddr = ioremap(PCMCIA_MACRO_PADDR, PCMCIA_MACRO_WINSIZE);
-
- if (pcmcia_macro_vaddr == NULL) {
- printk(KERN_ERR "pccf_4xx: ioremap macro at 0x%x failed.\n",
- PCMCIA_MACRO_PADDR);
- return -EBUSY;
- }
-
- isa_io_base =
- (unsigned long) ioremap(PCMCIA_IO_PADDR, PCMCIA_IO_WINSIZE);
-
- if (isa_io_base == 0) {
- printk(KERN_ERR "pccf_4xx: ioremap io at 0x%x failed.\n",
- PCMCIA_IO_PADDR);
- return -EBUSY;
- }
-
- isa_mem_base = (unsigned long) ioremap(PCMCIA_MEM_PADDR,
- PCMCIA_MEM_WINSIZE);
-
- if (isa_mem_base == 0) {
- printk(KERN_ERR "pccf_4xx: ioremap mem at 0x%x failed.\n",
- PCMCIA_MEM_PADDR);
- return -EBUSY;
- }
-
- DEBUG(0, "pccf_4xx: Physical base address is 0x%08x\n", PCMCIA_PADDR);
+ DEBUG(0, "pccf_4xx: Physical base address is 0x%08lx\n", PCCF_4XX_PADDR);
DEBUG(0, "pccf_4xx: Virtual base addresses: macro=0x%p, mem=0x%lx"
- " io=0x%lx\n", pcmcia_macro_vaddr, _ISA_MEM_BASE, _IO_BASE);
+ " io=0x%lx\n", pccf_4xx_macro_vaddr, _ISA_MEM_BASE, _IO_BASE);
CardServices(GetCardServicesInfo, &serv);
if (serv.Revision != CS_RELEASE_CODE) {
@@ -1350,7 +1249,6 @@
return -EBUSY;
}
- ebc_setup(); /* Set up EBC (if not already) */
pcmcia_mrr(); /* Reset the PCCF Macro */
poweroff(); /* Make sure socket is powered down */
pcmcia_mask_cdi(); /* Mask card-detect interrupt */
@@ -1359,11 +1257,11 @@
/* Note that the PCMCIA macro interrupts are not shared. */
- socket[0].intr = MACRO_IRQ;
+ socket[0].intr = PCCF_4XX_MACRO_IRQ;
- if ((error = request_irq(MACRO_IRQ, pccf_4xx_interrupt, 0, "pcmcia",
+ if ((error = request_irq(PCCF_4XX_MACRO_IRQ, pccf_4xx_interrupt, 0, "pcmcia",
&socket[0])) != 0) {
- printk(KERN_ERR "pccf_4xx: IRQ %d not available!\n", MACRO_IRQ);
+ printk(KERN_ERR "pccf_4xx: IRQ %d not available!\n", PCCF_4XX_MACRO_IRQ);
return error;
}
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/include/asm-ppc/pccf_4xx.h linux-bartholomew/include/asm-ppc/pccf_4xx.h
--- /home/dgibson/kernel/linuxppc_2_4_devel/include/asm-ppc/pccf_4xx.h Thu Jan 01 10:00:00 1970
+++ linux-bartholomew/include/asm-ppc/pccf_4xx.h Thu Jan 09 16:44:25 2003
@@ -0,0 +1,27 @@
+#ifndef __ASM_PCCF_4XX_H
+#define __ASM_PCCF_4XX_H
+
+/* Areas that we ioremap() are mapped only as large as necessary to get the job
+ done: Only a few locations of the macro space are used, and legacy IO space
+ is only 64 KB. There is 1 memory window, and 2 virtual IO windows. */
+
+#define PCCF_4XX_MACRO_OFFSET 0x00000000
+#define PCCF_4XX_MACRO_PADDR (PCCF_4XX_PADDR + PCCF_4XX_MACRO_OFFSET)
+#define PCCF_4XX_MACRO_WINSIZE PAGE_SIZE
+
+#define PCCF_4XX_MEM_OFFSET 0x01000000
+#define PCCF_4XX_MEM_PADDR (PCCF_4XX_PADDR + PCCF_4XX_MEM_OFFSET)
+#define PCCF_4XX_MEM_WINSIZE (8 * 1024 * 1024)
+
+#define PCCF_4XX_IO_OFFSET 0x01800000
+#define PCCF_4XX_IO_PADDR (PCCF_4XX_PADDR + PCCF_4XX_IO_OFFSET)
+#define PCCF_4XX_IO_WINSIZE 0x00010000
+
+/* These are declared here, since the pccf_4xx driver needs them, but
+ * must be defined and initialized by the board setup code. */
+extern volatile u16 *pccf_4xx_macro_vaddr;
+extern unsigned long pccf_4xx_io_base;
+extern unsigned long pccf_4xx_mem_base;
+
+#endif /* __ASM_PCCF_4XX_H */
+
--
David Gibson | For every complex problem there is a
david@gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: detecting hyperthreading in linux 2.4.19
From: Mike Dresser @ 2003-01-10 0:58 UTC (permalink / raw)
To: John Bradford; +Cc: jamesclv, lunz, linux-kernel
In-Reply-To: <200301092154.h09Ls5SX005123@darkstar.example.net>
On Thu, 9 Jan 2003, John Bradford wrote:
> If /proc/interrupts shows a processor is handling interrupts then it
> is definitely a 'real' one. If it isn't handling interrupts, it may
> or may not be a 'real' one. That's another unreliable and kludgey way
> to tell the difference :-).
What about something like lmsensors? Wouldn't the motherboard normally
report different temperatures for each cpu, since each has its own temp
diode?
(this originally was supposed to be a in-jest idea to run two threads and
see if one cpu or two cpu's heat up, but then i realized you might as well
just count the temperature diodes :D)
Mike
^ permalink raw reply
* Re: lifecycle of a packet
From: Joel Newkirk @ 2003-01-10 0:47 UTC (permalink / raw)
To: Tony Clayton, netfilter
In-Reply-To: <1042152892.3e1dfdbc6f5d1@webmail.enfusion-group.com>
On Thursday 09 January 2003 05:54 pm, Tony Clayton wrote:
> I've been reading the various docs linked to from netfilter.org,
> hoping to figure out the exact order in which a packet traverses the
> various tables and chains as it passes through the network stack.
>
> Unfortunately, I couldn't find a definative resource that contained
> this information, so I decided to figure it out myself.
Oskar's tutorial at http://iptables-tutorial.frozentux.net covers it
pretty nicely, although his main diagrams and tables don't clarify the
single-hit nature of the NAT chains. (he covers this elsewhere)
> I build a quick script to insert LOG rules into every chain of every
> table, so that I could log the order in which the tables and chains
> are traversed.
That's the best solution anyway. Until you do it yourself you can't
/really/ know it, and IIRC some earlier versions traversals were
slightly different. (All through my childhood my mom had a sign in one
room "I hear and I forget, I see and I remember, I do and I understand"
which seems pretty accurate usually :^)
> Here are my findings, using the three test cases below:
[snipped]
> This is quite interesting, and not at all what I was expecting based
> on what I'd read.
One you missed, which threw me when I first discovered it: Firewall box
to itself. This one bypasses nat PREROUTING entirely... I guess since
it's inbound on interface lo then there is only one rational destination
anyway, so that chain would be pretty much useless. If you want to DNAT
a localhost connection you do it in nat OUTPUT.
> I have a list of questions about this behaviour, keeping in mind that
> I'm fairly new to iptables/netfilter:
>
> 1. Why does only the first packet for a TCP/IP connection seem to pass
> through the nat table? Does connection tracking take over if the
> packet is (ESTABLISHED,RELATED) and work some magic under the covers?
Precisely, plus some. Even if you don't have an 'EST/REL' rule,
conntrack's still there under the hood. (check "lsmod | grep ip" and
you'll see that ip_conntrack is a dependancy for iptable_nat) This is
how netfilter knows that return traffic IS return traffic, and what IP
to forward it back to when unSNATting packets.
> 2. Why do both OUTPUT and POSTROUTING chains get traversed for packets
> that the firewall sends out? Is this useful at all?
As an example, you can DNAT in nat OUTPUT, (but not POSTROUTING - the
routing decision has already been made) to allow you to change
destination without the local process knowing or needing to know. You
can SNAT in nat POSTROUTING but not OUTPUT. You can change TTL in
mangle POSTROUTING for all packets, whether OUTPUT or FORWARD fed them
in, so that for example they are all the same, (a few ISP's apparently
look for differing TTL's when policing for 'hidden' machines that they
want to charge connection fees for) and you can change TOS or mark in
mangle OUTPUT so that routing can be based on those, which again has
already been decided before the packet reaches any POSTROUTING chains.
> 3. Most of the documents I looked at were fairly old. Is there a
> somewhat recent document that perhaps might benefit from including
> these tests?
Oskar Andreasson's tutorial is updated and tweaked frequently, I believe
he announced the latest update on this list Dec 19. The only references
I've EVER used for iptables are his tutorial and the main documentation.
He also recommends setting up log rules the way you did to double-check
that traversal works the way you believe it does.
> thanks,
>
> Tony
j
^ permalink raw reply
* Re: 2.4.20, .text.lock.swap cpu usage? (ibm x440)
From: William Lee Irwin III @ 2003-01-10 0:55 UTC (permalink / raw)
To: Brian Tinsley; +Cc: Andrew Morton, Chris Wood, linux-kernel
In-Reply-To: <3E1E175A.1050109@emageon.com>
At some point in the past, I wrote:
>> Either pollwait tables (invisible in 2.4 and 2.5), kernel stacks of
>> threads (which don't get pae_pgd's and are hence invisible in 2.4
>> and 2.5), or pagecache, with a much higher likelihood of pagecache.
On Thu, Jan 09, 2003 at 06:44:10PM -0600, Brian Tinsley wrote:
> The "kernel stacks of threads" may have some bearing on my incarnation
> of this problem. We have several heavily threaded Java applications
> running at the time the live-locks occur. At our most problematic site,
> one application has a bug that can cause hundreds of timer threads (I
> mean like 800 or so!) to be "accidentally" created. This site is
> scheduled for an upgrade either tonight or tomorrow, so I will leave the
> system as it is and see if I can still cause the live-lock to manifest
> itself after the upgrade.
There is no extant implementation of paged stacks yet. I'm working on
a different problem (mem_map on 64GB on 2.5.x). I probably won't have
time to implement it in the near future, I probably won't be doing it
vs. 2.4.x, and I won't have to if someone else does it first.
Bill
^ permalink raw reply
* Re: kswapd CPU usage and heavy disk IO
From: William Lee Irwin III @ 2003-01-10 0:46 UTC (permalink / raw)
To: Dieter N?tzel
Cc: Brian Tinsley, Russell Coker, ReiserFS, Rik van Riel,
Andrea Arcangeli, Linux Kernel List
In-Reply-To: <200301091742.51101.Dieter.Nuetzel@hamburg.de>
[-- Attachment #1: brief message --]
[-- Type: text/plain, Size: 1604 bytes --]
Am Donnerstag, 9. Januar 2003 17:02 schrieb Brian Tinsley:
>> I've been seeing the exact same thing on the same type of system in the
>> same situations. This has been causing all kinds of problems on our
>> clusters: the system live-locks for a minute or two, causes cluster
>> heartbeats to not be received, and falsely fails over when the system
>> recovers from the live-lock. The only thing I can find after the
>> live-lock is that the runtime for kswapd is abnormally high.
>> We started running sar (60 second collection interval) and were able to
>> capture some stats during this live-lock period. I've snipped some I
>> believe may be of interest. Note the missing stats between 03:59:43 and
>> 04:02:03
>> Oh BTW, this is on a stock 2.4.20 kernel (dual P3, 4GB), but I have seen
>> the same behavior on 2.4.19 and 2.4.17.
On Thu, Jan 09, 2003 at 05:42:51PM +0100, Dieter N?tzel wrote:
> I think you should have cc'ed Andrea Arcangeli <andrea@suse.de>,
> LKM and try 2.4.20-aa1. Are you sure it is a ReiserFS and not a
> kernel thing?
There simply aren't enough scenarios for this to be a mystery. Both
-aa and 2.5.x should have something in there for it: memclass-related
buffer_head stuff in -aa, and bh-stripping + "bh-less" operation (for
ext2) in 2.5.x + fewer (if any) bh's outside of actual dirty data.
Bloat monitoring scripts attached, which might provide somewhat more
useful output to capture, though they certainly don't eliminate the
need for /proc/meminfo logging. I'll also see if some of the accounting
patches can be backported and send those to Marcelo and Andrea.
Bill
[-- Attachment #2: bloatmon --]
[-- Type: text/plain, Size: 413 bytes --]
#!/usr/bin/awk -f
BEGIN {
printf "%18s %8s %8s %8s\n", "cache", "active", "alloc", "%util";
}
{
if ($3 != 0.0) {
pct = 100.0 * $2 / $3;
frac = (10000.0 * $2 / $3) % 100;
} else {
pct = 100.0;
frac = 0.0;
}
active = ($2 * $4)/1024;
alloc = ($3 * $4)/1024;
if ((alloc - active) < 1.0) {
pct = 100.0;
frac = 0.0;
}
printf "%18s: %8dKB %8dKB %3d.%-2d\n", $1, active, alloc, pct, frac;
}
[-- Attachment #3: bloatmeter --]
[-- Type: text/plain, Size: 133 bytes --]
#!/bin/sh
while : ; do
grep -v '^slabinfo' /proc/slabinfo \
| bloatmon \
| sort -n -k 4,4 \
| head -22
sleep 5
echo
done
[-- Attachment #4: bloatmost --]
[-- Type: text/plain, Size: 110 bytes --]
#!/bin/sh
while true
do
bloatmon < /proc/slabinfo \
| sort -rn -k 3,3 \
| head -22
sleep 60
echo
done
^ 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.