* Re: 2.4.19 -- ac97_codec failure ALi 5451
From: Alan Cox @ 2003-01-10 13:36 UTC (permalink / raw)
To: Peter; +Cc: linux-kernel, Alan Cox
In-Reply-To: <1042204553.3e1ec789564b6@webmail.cogweb.net>
> I've downloaded the latest driver and am running 2.4.20 (yea!) -- the trident.c here
> is actually more recent than 2.5.55. It now loads fast and with no protest from
> ac97_codec, which has a new ID (ADS114). However, there's still not a peep (I try
> cat test.mp3 > /dev/dsp) -- and when KDE Control Center tries to restart the arts
> sound server, it alarmingly fails on "CPU overload" or just freezes the whole
> system. Is there anything I can do to get more information about what is not
> happening?
No but the info is very useful. The key change involving ac97 is that the
new code in 2.4.x waits much longer for the codec reset to finish. I'm not
sure where the audio has gone however 8(
^ permalink raw reply
* Re: aal_assert()
From: Andrew Clausen @ 2003-01-10 13:26 UTC (permalink / raw)
To: Nikita Danilov; +Cc: reiserfs-list
In-Reply-To: <15901.23872.24060.68353@laputa.namesys.com>
On Thu, Jan 09, 2003 at 02:30:08PM +0300, Nikita Danilov wrote:
> These "message ids" are traditional way reiserfs code uses to identify
> errors (probably because early during development preprocessor features
> were unknown) and Hans feels himself attached to them emotionally. :-)
Well, I'll give some arguments against this scheme:
(1) it's more code, more work, more space, etc. Programmers are
minimalists, and adding extra stuff feels dirty.
(2) "ids" are the Wrong Way to identify things... things should
be identified by their essence, not by tags. This is the whole
OO vs relational database flamewar. Relational databases
(the "by essense/being, not tag") won, game over.
You don't query things by tags, but by what they are.
I know this is all quite subjective... I just wanted to provide
some emotional arguments as well as rational ones *grin*
Another thing: I'd like to see libaal reused in all file system
tool implementations. That's my main motivation for cleaning it
up. My first target is ntfs...
Cheers,
Andrew
^ permalink raw reply
* Re: [patch] R4k cache code synchronization
From: Juan Quintela @ 2003-01-10 13:33 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Ralf Baechle, linux-mips
In-Reply-To: <Pine.GSO.3.96.1030110131859.23678B-100000@delta.ds2.pg.gda.pl>
I agree with the cleanup.
The only thing that could be controversial is the _l1() thing, and as
current thing is broken, I vote for insclusion.
maciej> diff -up --recursive --new-file linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c
maciej> --- linux-mips-2.4.20-pre6-20030107.macro/arch/mips64/mm/c-r4k.c 2002-12-20 03:56:52.000000000 +0000
maciej> +++ linux-mips-2.4.20-pre6-20030107/arch/mips64/mm/c-r4k.c 2003-01-09 23:21:39.000000000 +0000
@@ -979,7 +980,7 @@ static void r4k_dma_cache_wback_inv_sc(u
unsigned long end, a;
if (size >= scache_size) {
- flush_cache_l1();
+ flush_cache_all();
return;
}
This one is fixing a bug, we are talking about a chip with Secondary
cache and don't touch the secondary cache at all :(
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
^ permalink raw reply
* Re: [PATCH]Re: spin_locks without smp.
From: Alan Cox @ 2003-01-10 14:19 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Maciej Soltysiak, Linux Kernel Mailing List
In-Reply-To: <20030110130446.GR23814@holomorphy.com>
On Fri, 2003-01-10 at 13:04, William Lee Irwin III wrote:
> Okay, what I'm getting here is that the UP case already has preempt
> disabled b/c the locks are taken in IRQ context?
The tx/timeout path isnt always in IRQ context. It may have pre-empt
disabled I'm just playing safe
> The thing I don't get is how the spinlock bits cause horrendous
> timing issues on UP that are different from SMP, esp. b/c they are
> #ifdef'd elsewhere to do nothing but inc/dec preempt_count elsewhere.
> There's a bit of "how did it happen" missing in my mind at least
Take a look at 8390.c for the whole how to do it SMP thing. That took
2 months to debug. For junk like the eexpress I've taken the attitude
that people who stick on in an SMP box deserve what tkey get. OTOH
lots of old single cpu boxes ues them and with the ifdef stuff in they
are perfectly usable cards for firewalls, linux terminal server recycled
PC's in schools and so forth.
> > preempt_disable()
> > disable_irq()
> > #ifdef CONFIG_SMP
> > spin_lock_...
> > #endif
>
> Hmm, the part I'm missing here is why folding the preempt_disable()
> into the spin_lock() is wrong. Or is it the implicit local_irq_save()
> that's the (massive performance) problem?
Its the implicit irqsave we need to avoid
> I'm tied up with 64GB at the moment so my wetware cpu cycles are really
> totally unavailable for this. =(
Commiserations. I suspect the ethernet stuff is easier.
Alan
^ permalink raw reply
* PATCH: add PRE_ROUTING and POST_ROUTING to filter table
From: Krzysztof Olędzki @ 2003-01-10 13:23 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 425 bytes --]
Hello,
This patch adds support for NF_IP_PRE_ROUTING and NF_IP_POST_ROUTING for
filter table.
Now, on linux router, it is possible to block with one rule all traffic
from specific source or to specific destination. Previously, in such
situations, two rules were required (one in FORWARD and one in
INPUT/OUTPUT).
This patch was tested with 2.4.20 and 2.4.50 kernels.
Best regards,
Krzysztof Olędzki
[-- Attachment #2: Type: APPLICATION/OCTET-STREAM, Size: 1273 bytes --]
^ permalink raw reply
* RE: SELF: compile of util-linux
From: James Don @ 2003-01-10 13:22 UTC (permalink / raw)
To: 'linuxppc-embedded@lists.linuxppc.org'
PLEASE IGNORE THIS ENTIRE POST ...
I figured out what I needed to know ... man patch ;-)
-----Original Message-----
From: James Don
Sent: Thursday, January 09, 2003 8:44 PM
To: James Don; 'linuxppc-embedded@lists.linuxppc.org'
Subject: RE: SELF: compile of util-linux
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
* Re: Linux 2.4.21pre3-ac2
From: Ralf Hildebrandt @ 2003-01-10 13:30 UTC (permalink / raw)
To: Linux Kernel Mailing List
In-Reply-To: <20030110111547.GB18007@charite.de>
* Ralf Hildebrandt <Ralf.Hildebrandt@charite.de>:
> * Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > On Fri, 2003-01-10 at 09:45, Ralf Hildebrandt wrote:
> > > I got an oops with that kernel on two different machines:
> >
> > Can you build the kernel with the patch to mm/shmem.c reverted and
> > see if that fixes your crash ?
>
> Well, yes. Should I remove all changes to "mm/shmem.c" that are done
> from the ac2 patch?
Backing out of mm/shmem.c makess thee bug disappear. Unfortunately I
fforgot to applyy the keyboard pacth forr my Toshiba laptop, so I get
duplicate letters when typingg real fasst (as you caan see!)
The keyboard paccth:
--- drivers/char/keyboard.c.orig 2003-01-10 12:20:18.000000000 +0100
+++ drivers/char/keyboard.c 2003-01-10 14:28:24.000000000 +0100
@@ -95,6 +95,7 @@
static struct tty_struct **ttytab;
static struct kbd_struct * kbd = kbd_table;
static struct tty_struct * tty;
+static unsigned char prev_scancode;
void compute_shiftstate(void);
@@ -214,7 +215,16 @@
}
kbd = kbd_table + fg_console;
if ((raw_mode = (kbd->kbdmode == VC_RAW))) {
- put_queue(scancode | up_flag);
+ /* put_queue(scancode | up_flag); */
+ /* The following 'if' is a workaround for hardware *
+ * which sometimes send the key release event twice */
+ unsigned char next_scancode = scancode|up_flag;
+ if (up_flag && next_scancode==prev_scancode) {
+ /* unexpected 2nd release event */
+ } else {
+ prev_scancode=next_scancode;
+ put_queue(next_scancode);
+ }
/* we do not return yet, because we want to maintain
the key_down array, so that we have the correct
values when finishing RAW mode or when changing VT's */
--
Ralf Hildebrandt (Im Auftrag des Referat V a) Ralf.Hildebrandt@charite.de
Charite Campus Mitte Tel. +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze - Fax. +49 (0)30-450 570-916
Okay, so I have this coworker who believes that NT is God's Gift to Sysadmins.
There are lots of weird gods around, aren't they?
Yeah, he means Cthulu. That's the kind of OS he/she/it'd give as a gift.
^ permalink raw reply
* Re: aal_assert()
From: Yury Umanets @ 2003-01-10 13:19 UTC (permalink / raw)
To: Andrew Clausen; +Cc: Nikita Danilov, reiserfs-list
In-Reply-To: <20030110132628.GA1056@gnu.org>
Andrew Clausen wrote:
>On Thu, Jan 09, 2003 at 02:30:08PM +0300, Nikita Danilov wrote:
>
>
>>These "message ids" are traditional way reiserfs code uses to identify
>>errors (probably because early during development preprocessor features
>>were unknown) and Hans feels himself attached to them emotionally. :-)
>>
>>
>Well, I'll give some arguments against this scheme:
>
>(1) it's more code, more work, more space, etc. Programmers are
>minimalists, and adding extra stuff feels dirty.
>
>(2) "ids" are the Wrong Way to identify things... things should
>be identified by their essence, not by tags. This is the whole
>OO vs relational database flamewar. Relational databases
>(the "by essense/being, not tag") won, game over.
>
>You don't query things by tags, but by what they are.
>
>I know this is all quite subjective... I just wanted to provide
>some emotional arguments as well as rational ones *grin*
>
>
>Another thing: I'd like to see libaal reused in all file system
>tool implementations. That's my main motivation for cleaning it
>up. My first target is ntfs...
>
It is more reasonable. Probably Hans will agree with you because of this.
>
>Cheers,
>Andrew
>
>
>
>
>
--
Yury Umanets
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: Alan Cox @ 2003-01-10 14:13 UTC (permalink / raw)
To: Andre Hedrick; +Cc: fverscheure, Linux Kernel Mailing List, Marcelo Tosatti
In-Reply-To: <Pine.LNX.4.10.10301100502450.31168-100000@master.linux-ide.org>
On Fri, 2003-01-10 at 13:03, Andre Hedrick wrote:
> Oh, just let the darn thing barf a 0x51/0x04 is fine with me!
> Just an abort/unsupported command.
Sounds ok to me. We do need a barfsupressor option so we can issue
commands that may fail without confusing the user (eg multiwrite setup)
ie
ide_hwif_barfsupress(hwif);
ide_command....
That's very much true irrespective of the flush thing
^ permalink raw reply
* Re: remove usage of __MOD_XXX_USAGE_COUNT and derivatives
From: Harald Welte @ 2003-01-10 13:13 UTC (permalink / raw)
To: Anders Fugmann; +Cc: netfilter-devel
In-Reply-To: <3E1DEF2D.4080703@fugmann.dhs.org>
[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]
On Thu, Jan 09, 2003 at 10:52:45PM +0100, Anders Fugmann wrote:
> Hi.
>
> Attached is a trivial patch the converts the usage of the macros
> __MOD_INC_USAGE_COUNT and __MOD_DEC_USAGE_COUNT to try_modules_get and
> module_put.
Ok, this seems to be some new 2.5.x api changes - I first need to get
familiar with this.
> Conversion enables module unloading on 2.5 kernels.
> The patch is against 2.5.55. I have only tested ipv4 functionality, and
> I see no reason that ipv6 shound not work also.
> Please examine the patch, and if ok I will send it to Linus for kernel
> inclusion (Unless someone on the list is the preferred person to do so -
> maybe Harald Welte?).
Patches are usually submitted to the respective maintainers (see the
MAINTAINERS file in the kernel source.
So if the patch is accepted (still need to look at it), I will submit it
for kernel inclusion.
> Regards
> Anders Fugmann
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* [parisc-linux] kernel compilation
From: FARINATI,LEANDRO (HP-Brazil,ex1) @ 2003-01-10 13:12 UTC (permalink / raw)
To: Parisc-Linux List (E-mail)
Hi people,
I'm trying compile the kernel linux-2.4.20-pa13 in a 64 bit machine
(pa risc 5430) with compiler gcc version 3.0.4 and occurs the following
problem:
hppa64-linux-gcc -D__KERNEL__ -I/usr/src/linux-2.4.20-pa13/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-fomit-frame-pointer -D__linux__ -pipe -fno-strength-reduce
-mno-space-regs -mfast-indirect-calls -mdisable-fpregs -ffunction-sections
-march=2.0 -mschedule=8000 -nostdinc -I
/usr/lib/gcc-lib/hppa-linux/3.0.4/include -DKBUILD_BASENAME=sys_parisc32 -c
-o sys_pa
risc32.o sys_parisc32.c
sys_parisc32.c:351: parse error before "__kernel_time_t32"
sys_parisc32.c:351: warning: no semicolon at end of struct or union
sys_parisc32.c:352: warning: type defaults to `int' in declaration of
`modtime'
sys_parisc32.c:352: warning: data definition has no type or storage class
sys_parisc32.c: In function `sys32_utime':
sys_parisc32.c:357: storage size of `times32' isn't known
sys_parisc32.c:357: warning: unused variable `times32'
sys_parisc32.c: At top level:
sys_parisc32.c:386: parse error before "__kernel_clock_t32"
sys_parisc32.c:386: warning: no semicolon at end of struct or union
sys_parisc32.c:387: warning: type defaults to `int' in declaration of
`tms_stime'
sys_parisc32.c:387: warning: data definition has no type or storage class
sys_parisc32.c:388: parse error before "tms_cutime"
sys_parisc32.c:388: warning: type defaults to `int' in declaration of
`tms_cutime'
sys_parisc32.c:388: warning: data definition has no type or storage class
sys_parisc32.c:389: parse error before "tms_cstime"
sys_parisc32.c:389: warning: type defaults to `int' in declaration of
`tms_cstime'
sys_parisc32.c:389: warning: data definition has no type or storage class
sys_parisc32.c: In function `sys32_times':
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:401: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:402: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:403: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c:404: dereferencing pointer to incomplete type
sys_parisc32.c: At top level:
sys_parisc32.c:414: parse error before "__kernel_off_t32"
sys_parisc32.c:414: warning: no semicolon at end of struct or union
sys_parisc32.c:415: warning: type defaults to `int' in declaration of
`l_len'
sys_parisc32.c:415: warning: data definition has no type or storage class
sys_parisc32.c:416: parse error before "l_pid"
sys_parisc32.c:416: warning: type defaults to `int' in declaration of
`l_pid'
sys_parisc32.c:416: warning: data definition has no type or storage class
sys_parisc32.c: In function `get_flock':
sys_parisc32.c:424: dereferencing pointer to incomplete type
sys_parisc32.c:424: dereferencing pointer to incomplete type
sys_parisc32.c:424: dereferencing pointer to incomplete type
sys_parisc32.c:424: dereferencing pointer to incomplete type
sys_parisc32.c:424: dereferencing pointer to incomplete type
sys_parisc32.c:424: dereferencing pointer to incomplete type
sys_parisc32.c:424: dereferencing pointer to incomplete type
sys_parisc32.c:424: dereferencing pointer to incomplete type
sys_parisc32.c:424: dereferencing pointer to incomplete type
sys_parisc32.c:424: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:425: dereferencing pointer to incomplete type
sys_parisc32.c:425: dereferencing pointer to incomplete type
sys_parisc32.c:425: dereferencing pointer to incomplete type
sys_parisc32.c:425: dereferencing pointer to incomplete type
sys_parisc32.c:425: dereferencing pointer to incomplete type
sys_parisc32.c:425: dereferencing pointer to incomplete type
sys_parisc32.c:425: dereferencing pointer to incomplete type
sys_parisc32.c:425: dereferencing pointer to incomplete type
sys_parisc32.c:425: dereferencing pointer to incomplete type
sys_parisc32.c:425: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:426: dereferencing pointer to incomplete type
sys_parisc32.c:426: dereferencing pointer to incomplete type
sys_parisc32.c:426: dereferencing pointer to incomplete type
sys_parisc32.c:426: dereferencing pointer to incomplete type
sys_parisc32.c:426: dereferencing pointer to incomplete type
sys_parisc32.c:426: dereferencing pointer to incomplete type
sys_parisc32.c:426: dereferencing pointer to incomplete type
sys_parisc32.c:426: dereferencing pointer to incomplete type
sys_parisc32.c:426: dereferencing pointer to incomplete type
sys_parisc32.c:426: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:427: dereferencing pointer to incomplete type
sys_parisc32.c:427: dereferencing pointer to incomplete type
sys_parisc32.c:427: dereferencing pointer to incomplete type
sys_parisc32.c:427: dereferencing pointer to incomplete type
sys_parisc32.c:427: dereferencing pointer to incomplete type
sys_parisc32.c:427: dereferencing pointer to incomplete type
sys_parisc32.c:427: dereferencing pointer to incomplete type
sys_parisc32.c:427: dereferencing pointer to incomplete type
sys_parisc32.c:427: dereferencing pointer to incomplete type
sys_parisc32.c:427: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:428: dereferencing pointer to incomplete type
sys_parisc32.c:428: dereferencing pointer to incomplete type
sys_parisc32.c:428: dereferencing pointer to incomplete type
sys_parisc32.c:428: dereferencing pointer to incomplete type
sys_parisc32.c:428: dereferencing pointer to incomplete type
sys_parisc32.c:428: dereferencing pointer to incomplete type
sys_parisc32.c:428: dereferencing pointer to incomplete type
sys_parisc32.c:428: dereferencing pointer to incomplete type
sys_parisc32.c:428: dereferencing pointer to incomplete type
sys_parisc32.c:428: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c: In function `put_flock':
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:436: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:437: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:438: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:439: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c:440: dereferencing pointer to incomplete type
sys_parisc32.c: In function `sys32_sysctl':
sys_parisc32.c:511: warning: cast to pointer from integer of different size
sys_parisc32.c:511: warning: cast to pointer from integer of different size
sys_parisc32.c:511: warning: cast to pointer from integer of different size
sys_parisc32.c:511: warning: cast to pointer from integer of different size
sys_parisc32.c:511: warning: cast to pointer from integer of different size
sys_parisc32.c:511: warning: cast to pointer from integer of different size
sys_parisc32.c:511: warning: cast to pointer from integer of different size
sys_parisc32.c:511: warning: cast to pointer from integer of different size
sys_parisc32.c:511: warning: cast to pointer from integer of different size
sys_parisc32.c:520: warning: cast to pointer from integer of different size
sys_parisc32.c:520: warning: cast to pointer from integer of different size
sys_parisc32.c:521: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c:529: warning: cast to pointer from integer of different size
sys_parisc32.c: At top level:
sys_parisc32.c:596: parse error before "time_t32"
sys_parisc32.c:596: warning: type defaults to `int' in declaration of
`time_t32'
sys_parisc32.c:596: warning: data definition has no type or storage class
sys_parisc32.c:621: parse error before '*' token
sys_parisc32.c:622: warning: function declaration isn't a prototype
sys_parisc32.c: In function `sys32_time':
sys_parisc32.c:624: parse error before "now32"
sys_parisc32.c:626: `tloc' undeclared (first use in this function)
sys_parisc32.c:626: (Each undeclared identifier is reported only once
sys_parisc32.c:626: for each function it appears in.)
sys_parisc32.c:627: `now32' undeclared (first use in this function)
sys_parisc32.c:623: warning: unused variable `now'
sys_parisc32.c:631: warning: control reaches end of non-void function
sys_parisc32.c: At top level:
sys_parisc32.c:786: parse error before "pid"
sys_parisc32.c:788: warning: function declaration isn't a prototype
sys_parisc32.c: In function `sys32_wait4':
sys_parisc32.c:789: `ru' undeclared (first use in this function)
sys_parisc32.c:790: `pid' undeclared (first use in this function)
sys_parisc32.c:790: `stat_addr' undeclared (first use in this function)
sys_parisc32.c:790: `options' undeclared (first use in this function)
sys_parisc32.c: At top level:
sys_parisc32.c:805: parse error before "__kernel_dev_t32"
sys_parisc32.c:805: warning: no semicolon at end of struct or union
sys_parisc32.c:806: warning: type defaults to `int' in declaration of
`st_ino'
sys_parisc32.c:806: warning: data definition has no type or storage class
sys_parisc32.c:807: parse error before "st_mode"
sys_parisc32.c:807: warning: type defaults to `int' in declaration of
`st_mode'
sys_parisc32.c:807: warning: data definition has no type or storage class
sys_parisc32.c:808: parse error before "st_nlink"
sys_parisc32.c:808: warning: type defaults to `int' in declaration of
`st_nlink'
sys_parisc32.c:808: warning: data definition has no type or storage class
sys_parisc32.c:811: parse error before "st_rdev"
sys_parisc32.c:811: warning: type defaults to `int' in declaration of
`st_rdev'
sys_parisc32.c:811: warning: data definition has no type or storage class
sys_parisc32.c:812: parse error before "st_size"
sys_parisc32.c:812: warning: type defaults to `int' in declaration of
`st_size'
sys_parisc32.c:812: warning: data definition has no type or storage class
sys_parisc32.c:813: parse error before "st_atime"
sys_parisc32.c:813: warning: type defaults to `int' in declaration of
`st_atime'
sys_parisc32.c:813: warning: data definition has no type or storage class
sys_parisc32.c:815: parse error before "st_mtime"
sys_parisc32.c:815: warning: type defaults to `int' in declaration of
`st_mtime'
sys_parisc32.c:815: warning: data definition has no type or storage class
sys_parisc32.c:817: parse error before "st_ctime"
sys_parisc32.c:817: warning: type defaults to `int' in declaration of
`st_ctime'
sys_parisc32.c:817: warning: data definition has no type or storage class
sys_parisc32.c:822: parse error before "__unused2"
sys_parisc32.c:822: warning: type defaults to `int' in declaration of
`__unused2'
sys_parisc32.c:822: warning: data definition has no type or storage class
sys_parisc32.c:823: parse error before "__unused3"
sys_parisc32.c:823: warning: type defaults to `int' in declaration of
`__unused3'
sys_parisc32.c:823: warning: data definition has no type or storage class
sys_parisc32.c:827: parse error before "st_realdev"
sys_parisc32.c:827: warning: type defaults to `int' in declaration of
`st_realdev'
sys_parisc32.c:827: warning: data definition has no type or storage class
sys_parisc32.c:830: parse error before "st_uid"
sys_parisc32.c:830: warning: type defaults to `int' in declaration of
`st_uid'
sys_parisc32.c:830: warning: data definition has no type or storage class
sys_parisc32.c:831: parse error before "st_gid"
sys_parisc32.c:831: warning: type defaults to `int' in declaration of
`st_gid'
sys_parisc32.c:831: warning: data definition has no type or storage class
sys_parisc32.c:833: parse error before '}' token
sys_parisc32.c: In function `cp_new_stat32':
sys_parisc32.c:850: storage size of `tmp' isn't known
sys_parisc32.c:850: warning: unused variable `tmp'
sys_parisc32.c:851: warning: `blocks' might be used uninitialized in this
function
sys_parisc32.c: At top level:
sys_parisc32.c:957: parse error before "__kernel_off_t32"
sys_parisc32.c:957: warning: no semicolon at end of struct or union
sys_parisc32.c:960: parse error before '}' token
sys_parisc32.c: In function `filldir32':
sys_parisc32.c:989: dereferencing pointer to incomplete type
sys_parisc32.c:989: dereferencing pointer to incomplete type
sys_parisc32.c:989: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:996: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:999: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1000: dereferencing pointer to incomplete type
sys_parisc32.c:1001: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c:1002: dereferencing pointer to incomplete type
sys_parisc32.c: In function `sys32_getdents':
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c:1033: dereferencing pointer to incomplete type
sys_parisc32.c: At top level:
sys_parisc32.c:1312: parse error before "__kernel_size_t32"
sys_parisc32.c:1313: warning: function declaration isn't a prototype
sys_parisc32.c: In function `qm_modules':
sys_parisc32.c:1321: `bufsize' undeclared (first use in this function)
sys_parisc32.c:1323: `buf' undeclared (first use in this function)
sys_parisc32.c:1330: `ret' undeclared (first use in this function)
sys_parisc32.c: At top level:
sys_parisc32.c:1347: parse error before "__kernel_size_t32"
sys_parisc32.c:1348: warning: function declaration isn't a prototype
sys_parisc32.c: In function `qm_deps':
sys_parisc32.c:1351: `mod' undeclared (first use in this function)
sys_parisc32.c:1354: `ret' undeclared (first use in this function)
sys_parisc32.c:1361: `bufsize' undeclared (first use in this function)
sys_parisc32.c:1363: `buf' undeclared (first use in this function)
sys_parisc32.c: At top level:
sys_parisc32.c:1384: parse error before "__kernel_size_t32"
sys_parisc32.c:1385: warning: function declaration isn't a prototype
sys_parisc32.c: In function `qm_refs':
sys_parisc32.c:1389: `mod' undeclared (first use in this function)
sys_parisc32.c:1392: `ret' undeclared (first use in this function)
sys_parisc32.c:1402: `bufsize' undeclared (first use in this function)
sys_parisc32.c:1404: `buf' undeclared (first use in this function)
sys_parisc32.c: At top level:
sys_parisc32.c:1428: parse error before "__kernel_size_t32"
sys_parisc32.c:1429: warning: function declaration isn't a prototype
sys_parisc32.c: In function `qm_symbols':
sys_parisc32.c:1435: `mod' undeclared (first use in this function)
sys_parisc32.c:1436: `ret' undeclared (first use in this function)
sys_parisc32.c:1446: `bufsize' undeclared (first use in this function)
sys_parisc32.c:1453: `buf' undeclared (first use in this function)
sys_parisc32.c: At top level:
sys_parisc32.c:1487: parse error before "__kernel_size_t32"
sys_parisc32.c:1488: warning: function declaration isn't a prototype
sys_parisc32.c: In function `qm_info':
sys_parisc32.c:1491: `mod' undeclared (first use in this function)
sys_parisc32.c:1494: `bufsize' undeclared (first use in this function)
sys_parisc32.c:1504: `buf' undeclared (first use in this function)
sys_parisc32.c:1509: `ret' undeclared (first use in this function)
sys_parisc32.c: At top level:
sys_parisc32.c:1515: parse error before "__kernel_size_t32"
sys_parisc32.c:1516: warning: function declaration isn't a prototype
sys_parisc32.c: In function `sys32_query_module':
sys_parisc32.c:1521: `name_user' undeclared (first use in this function)
sys_parisc32.c:1545: `which' undeclared (first use in this function)
sys_parisc32.c:1551: `buf' undeclared (first use in this function)
sys_parisc32.c:1551: `bufsize' undeclared (first use in this function)
sys_parisc32.c:1551: `ret' undeclared (first use in this function)
sys_parisc32.c: At top level:
sys_parisc32.c:1791: parse error before "__kernel_size_t32"
sys_parisc32.c:1791: warning: no semicolon at end of struct or union
sys_parisc32.c:1793: parse error before "msg_controllen"
sys_parisc32.c:1793: warning: type defaults to `int' in declaration of
`msg_controllen'
sys_parisc32.c:1793: warning: data definition has no type or storage class
sys_parisc32.c:1795: parse error before '}' token
sys_parisc32.c:1798: parse error before "__kernel_size_t32"
sys_parisc32.c:1798: warning: no semicolon at end of struct or union
sys_parisc32.c:1801: parse error before '}' token
sys_parisc32.c: In function `__cmsg32_nxthdr':
sys_parisc32.c:1825: arithmetic on pointer to an incomplete type
sys_parisc32.c: In function `msghdr_from_user32_to_kern':
sys_parisc32.c:1869: dereferencing pointer to incomplete type
sys_parisc32.c:1869: dereferencing pointer to incomplete type
sys_parisc32.c:1869: dereferencing pointer to incomplete type
sys_parisc32.c:1869: dereferencing pointer to incomplete type
sys_parisc32.c:1869: dereferencing pointer to incomplete type
sys_parisc32.c:1869: dereferencing pointer to incomplete type
sys_parisc32.c:1869: dereferencing pointer to incomplete type
sys_parisc32.c:1869: dereferencing pointer to incomplete type
sys_parisc32.c:1869: dereferencing pointer to incomplete type
sys_parisc32.c:1869: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1870: dereferencing pointer to incomplete type
sys_parisc32.c:1870: dereferencing pointer to incomplete type
sys_parisc32.c:1870: dereferencing pointer to incomplete type
sys_parisc32.c:1870: dereferencing pointer to incomplete type
sys_parisc32.c:1870: dereferencing pointer to incomplete type
sys_parisc32.c:1870: dereferencing pointer to incomplete type
sys_parisc32.c:1870: dereferencing pointer to incomplete type
sys_parisc32.c:1870: dereferencing pointer to incomplete type
sys_parisc32.c:1870: dereferencing pointer to incomplete type
sys_parisc32.c:1870: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1871: dereferencing pointer to incomplete type
sys_parisc32.c:1871: dereferencing pointer to incomplete type
sys_parisc32.c:1871: dereferencing pointer to incomplete type
sys_parisc32.c:1871: dereferencing pointer to incomplete type
sys_parisc32.c:1871: dereferencing pointer to incomplete type
sys_parisc32.c:1871: dereferencing pointer to incomplete type
sys_parisc32.c:1871: dereferencing pointer to incomplete type
sys_parisc32.c:1871: dereferencing pointer to incomplete type
sys_parisc32.c:1871: dereferencing pointer to incomplete type
sys_parisc32.c:1871: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1879: dereferencing pointer to incomplete type
sys_parisc32.c:1879: dereferencing pointer to incomplete type
sys_parisc32.c:1879: dereferencing pointer to incomplete type
sys_parisc32.c:1879: dereferencing pointer to incomplete type
sys_parisc32.c:1879: dereferencing pointer to incomplete type
sys_parisc32.c:1879: dereferencing pointer to incomplete type
sys_parisc32.c:1879: dereferencing pointer to incomplete type
sys_parisc32.c:1879: dereferencing pointer to incomplete type
sys_parisc32.c:1879: dereferencing pointer to incomplete type
sys_parisc32.c:1879: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1880: dereferencing pointer to incomplete type
sys_parisc32.c:1880: dereferencing pointer to incomplete type
sys_parisc32.c:1880: dereferencing pointer to incomplete type
sys_parisc32.c:1880: dereferencing pointer to incomplete type
sys_parisc32.c:1880: dereferencing pointer to incomplete type
sys_parisc32.c:1880: dereferencing pointer to incomplete type
sys_parisc32.c:1880: dereferencing pointer to incomplete type
sys_parisc32.c:1880: dereferencing pointer to incomplete type
sys_parisc32.c:1880: dereferencing pointer to incomplete type
sys_parisc32.c:1880: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1881: dereferencing pointer to incomplete type
sys_parisc32.c:1881: dereferencing pointer to incomplete type
sys_parisc32.c:1881: dereferencing pointer to incomplete type
sys_parisc32.c:1881: dereferencing pointer to incomplete type
sys_parisc32.c:1881: dereferencing pointer to incomplete type
sys_parisc32.c:1881: dereferencing pointer to incomplete type
sys_parisc32.c:1881: dereferencing pointer to incomplete type
sys_parisc32.c:1881: dereferencing pointer to incomplete type
sys_parisc32.c:1881: dereferencing pointer to incomplete type
sys_parisc32.c:1881: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1882: dereferencing pointer to incomplete type
sys_parisc32.c:1882: dereferencing pointer to incomplete type
sys_parisc32.c:1882: dereferencing pointer to incomplete type
sys_parisc32.c:1882: dereferencing pointer to incomplete type
sys_parisc32.c:1882: dereferencing pointer to incomplete type
sys_parisc32.c:1882: dereferencing pointer to incomplete type
sys_parisc32.c:1882: dereferencing pointer to incomplete type
sys_parisc32.c:1882: dereferencing pointer to incomplete type
sys_parisc32.c:1882: dereferencing pointer to incomplete type
sys_parisc32.c:1882: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c: In function `cmsghdr_from_user32_to_kern':
sys_parisc32.c:1932: `__kernel_size_t32' undeclared (first use in this
function)
sys_parisc32.c:1932: parse error before "ucmlen"
sys_parisc32.c:1937: sizeof applied to an incomplete type
sys_parisc32.c:1939: dereferencing pointer to incomplete type
sys_parisc32.c:1939: dereferencing pointer to incomplete type
sys_parisc32.c:1939: dereferencing pointer to incomplete type
sys_parisc32.c:1939: dereferencing pointer to incomplete type
sys_parisc32.c:1939: dereferencing pointer to incomplete type
sys_parisc32.c:1939: dereferencing pointer to incomplete type
sys_parisc32.c:1939: dereferencing pointer to incomplete type
sys_parisc32.c:1939: dereferencing pointer to incomplete type
sys_parisc32.c:1939: `ucmlen' undeclared (first use in this function)
sys_parisc32.c:1939: dereferencing pointer to incomplete type
sys_parisc32.c:1939: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1944: sizeof applied to an incomplete type
sys_parisc32.c:1950: dereferencing pointer to incomplete type
sys_parisc32.c:1970: sizeof applied to an incomplete type
sys_parisc32.c:1972: dereferencing pointer to incomplete type
sys_parisc32.c:1972: dereferencing pointer to incomplete type
sys_parisc32.c:1972: dereferencing pointer to incomplete type
sys_parisc32.c:1972: dereferencing pointer to incomplete type
sys_parisc32.c:1972: dereferencing pointer to incomplete type
sys_parisc32.c:1972: dereferencing pointer to incomplete type
sys_parisc32.c:1972: dereferencing pointer to incomplete type
sys_parisc32.c:1972: dereferencing pointer to incomplete type
sys_parisc32.c:1972: dereferencing pointer to incomplete type
sys_parisc32.c:1972: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1973: dereferencing pointer to incomplete type
sys_parisc32.c:1976: dereferencing pointer to incomplete type
sys_parisc32.c:1976: dereferencing pointer to incomplete type
sys_parisc32.c:1976: dereferencing pointer to incomplete type
sys_parisc32.c:1976: dereferencing pointer to incomplete type
sys_parisc32.c:1976: dereferencing pointer to incomplete type
sys_parisc32.c:1976: dereferencing pointer to incomplete type
sys_parisc32.c:1976: dereferencing pointer to incomplete type
sys_parisc32.c:1976: dereferencing pointer to incomplete type
sys_parisc32.c:1976: dereferencing pointer to incomplete type
sys_parisc32.c:1976: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1977: dereferencing pointer to incomplete type
sys_parisc32.c:1977: dereferencing pointer to incomplete type
sys_parisc32.c:1977: dereferencing pointer to incomplete type
sys_parisc32.c:1977: dereferencing pointer to incomplete type
sys_parisc32.c:1977: dereferencing pointer to incomplete type
sys_parisc32.c:1977: dereferencing pointer to incomplete type
sys_parisc32.c:1977: dereferencing pointer to incomplete type
sys_parisc32.c:1977: dereferencing pointer to incomplete type
sys_parisc32.c:1977: dereferencing pointer to incomplete type
sys_parisc32.c:1977: warning: type defaults to `int' in declaration of `type
name'
sys_parisc32.c:1981: sizeof applied to an incomplete type
sys_parisc32.c:1982: dereferencing pointer to incomplete type
sys_parisc32.c: In function `put_cmsg32':
sys_parisc32.c:2005: storage size of `cmhdr' isn't known
sys_parisc32.c:2006: sizeof applied to an incomplete type
sys_parisc32.c:2008: dereferencing pointer to incomplete type
sys_parisc32.c:2023: sizeof applied to an incomplete type
sys_parisc32.c:2023: sizeof applied to an incomplete type
sys_parisc32.c:2025: sizeof applied to an incomplete type
sys_parisc32.c:2005: warning: unused variable `cmhdr'
sys_parisc32.c: In function `scm_detach_fds32':
sys_parisc32.c:2033: sizeof applied to an incomplete type
sys_parisc32.c:2042: sizeof applied to an incomplete type
sys_parisc32.c:2059: sizeof applied to an incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2061: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2063: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2065: dereferencing pointer to incomplete type
sys_parisc32.c:2067: sizeof applied to an incomplete type
sys_parisc32.c: In function `cmsg32_recvmsg_fixup':
sys_parisc32.c:2136: dereferencing pointer to incomplete type
sys_parisc32.c:2137: dereferencing pointer to incomplete type
sys_parisc32.c:2138: dereferencing pointer to incomplete type
sys_parisc32.c:2140: dereferencing pointer to incomplete type
sys_parisc32.c:2141: sizeof applied to an incomplete type
sys_parisc32.c:2144: sizeof applied to an incomplete type
sys_parisc32.c:2145: dereferencing pointer to incomplete type
sys_parisc32.c:2130: warning: `clen64' might be used uninitialized in this
function
sys_parisc32.c: In function `sys32_recvmsg':
sys_parisc32.c:2234: dereferencing pointer to incomplete type
sys_parisc32.c:2284: `__kernel_size_t32' undeclared (first use in this
function)
sys_parisc32.c:2284: parse error before "uclen"
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2285: `uclen' undeclared (first use in this function)
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2285: dereferencing pointer to incomplete type
sys_parisc32.c:2283: warning: unused variable `ucmsg_ptr'
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2288: dereferencing pointer to incomplete type
sys_parisc32.c:2224: warning: `uaddr_len' might be used uninitialized in
this function
sys_parisc32.c: In function `get_fd_set32':
sys_parisc32.c:2526: warning: left shift count >= width of type
sys_parisc32.c: In function `set_fd_set32':
sys_parisc32.c:2555: warning: right shift count >= width of type
sys_parisc32.c: At top level:
sys_parisc32.c:2782: parse error before "__kernel_ino_t32"
sys_parisc32.c:2782: warning: no semicolon at end of struct or union
sys_parisc32.c:2786: parse error before '}' token
sys_parisc32.c:2792: parse error before "__kernel_ino_t32"
sys_parisc32.c:2792: warning: no semicolon at end of struct or union
sys_parisc32.c:2794: parse error before '}' token
sys_parisc32.c:2798: parse error before "__kernel_caddr_t32"
sys_parisc32.c:2798: warning: no semicolon at end of struct or union
sys_parisc32.c:2801: parse error before "ug_udimap"
sys_parisc32.c:2801: warning: type defaults to `int' in declaration of
`ug_udimap'
sys_parisc32.c:2801: warning: data definition has no type or storage class
sys_parisc32.c:2804: parse error before "ug_gdimap"
sys_parisc32.c:2804: warning: type defaults to `int' in declaration of
`ug_gdimap'
sys_parisc32.c:2804: warning: data definition has no type or storage class
sys_parisc32.c:2813: field `u_export' has incomplete type
sys_parisc32.c:2814: field `u_umap' has incomplete type
sys_parisc32.c:2815: field `u_getfh' has incomplete type
sys_parisc32.c:2917: parse error before "__kernel_time_t32"
sys_parisc32.c:2917: warning: no semicolon at end of struct or union
sys_parisc32.c:2918: warning: type defaults to `int' in declaration of
`dqb_itime'
sys_parisc32.c:2918: warning: data definition has no type or storage class
sys_parisc32.c: In function `sys32_quotactl':
sys_parisc32.c:2937: sizeof applied to an incomplete type
sys_parisc32.c:2939: dereferencing pointer to incomplete type
sys_parisc32.c:2940: dereferencing pointer to incomplete type
sys_parisc32.c:2953: dereferencing pointer to incomplete type
sys_parisc32.c:2954: dereferencing pointer to incomplete type
sys_parisc32.c:2956: sizeof applied to an incomplete type
sys_parisc32.c:3008:1: warning: "CP" redefined
sys_parisc32.c:3001:1: warning: this is the location of the previous
definition
make[1]: *** [sys_parisc32.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.4.20-pa13/arch/parisc/kernel'
make: *** [_dir_arch/parisc/kernel] Error 2
Anyone know something about this?
-----------------------------------------------------------------------
Leandro Marcondes Farinati
Software Developer
* leandro.farinati@hp.com
* +55-51-3316-2852 Telnet 725-2852
FAX +55-51-3316-2754 Mobile +55-51-9965-8020
^ permalink raw reply
* Re: oops while unloading snd-intel8x0
From: Takashi Iwai @ 2003-01-10 13:11 UTC (permalink / raw)
To: Enrik Berkhan; +Cc: alsa-devel
In-Reply-To: <20030110123732.GE986@electra.intern.planb.de>
Hi Enrik,
At Fri, 10 Jan 2003 13:37:32 +0100,
Enrik Berkhan wrote:
>
> Hi,
>
> At Tue, 10 Dec 2002 08:39:35 -0800, Takashi Iwai wrote:
> > At Tue, 10 Dec 2002 13:50:31 +0100, Christian Guggenberger wrote:
> > > I get following oops while unloading snd-intel8x0 on a Dell Optiplex 260
> > hmm, it's a new type of oops, which i've never seen.
>
> I had the same problem using a Gericom Frontman (SiS 7012). It turned out
> that unregistering the joystick_driver while no joystick had been found
> on init caused the oops.
Ah, thanks for pointing out!
> Proposed patch:
>
> --- intel8x0.c.orig Mon Oct 28 12:56:35 2002
> +++ intel8x0.c Thu Jan 9 13:13:21 2003
> @@ -1783,6 +1783,9 @@
> } while (time_after_eq(end_time, jiffies));
>
> __ok3:
> + if (chip->device_type == DEVICE_SIS) {
> + iputword(chip, 0x4c, igetword(chip, 0x4c) | 1);
> + }
> return 0;
> }
>
what initializes this?
does it fix the silent problem on sis7012?
other changes look fine (printk would be snd_printdd only for debug
messages).
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Executing NAT and iptables on SUMSUNG S3C4510B
From: Harald Welte @ 2003-01-10 13:10 UTC (permalink / raw)
To: Cheng,Yu-Chin; +Cc: netfilter-devel
In-Reply-To: <3E1D4A17.5040309@wiscore.com>
[-- Attachment #1: Type: text/plain, Size: 917 bytes --]
On Thu, Jan 09, 2003 at 06:08:23PM +0800, Cheng,Yu-Chin wrote:
> Jenny Cheng wrote:
>
> >
> >Dear all:
> >
> > I have some problems in executing kernel 2.4.19 image with NAT and
> >iptables supported on SAMSUNG S3C4510b.
> >
> > Please see the following information and give me some ideas.
> > Kernel about NETWORK configure options and system message.
> >
It seems like you are using ARP tables. They are experimental and
written by David Miller (davem@redhat.com).
We have never used them and don't even know the userspace configuration
ultilities exist...
> >*Best Regards
> >Jenny
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* sd_read_cache_type
From: Andries.Brouwer @ 2003-01-10 13:08 UTC (permalink / raw)
To: linux-kernel, linux-scsi, linux-usb-devel
Last year I wrote half a dozen drivers for various USB card readers.
Some don't work anymore with 2.5.recent.
I just investigated one. The reason it stopped working is the
sd_read_cache_type()
call added in 2.5.41. (With that call removed it works again.)
Will look a bit more at the details later.
For now a question: this call does a MODE_SENSE with the DBD
(disable block descriptors) bit set. Is there a reason for that?
Wouldn't the same code work in the same way without that bit?
And the reason I ask is that we already have sd_do_mode_sense6(),
so part of sd_read_cache_type() can be simply replaced by a call
of sd_do_mode_sense6(), but the latter needs an extra parameter
if DBD is really needed.
And a second question: sd_read_cache_type() is called also
when no medium is present. Objections against only calling
when media are present?
Andries
^ permalink raw reply
* Re: 2.4.19 -- ac97_codec failure ALi 5451
From: Peter @ 2003-01-10 13:15 UTC (permalink / raw)
To: linux-kernel; +Cc: Alan Cox
In-Reply-To: <200301100250.h0A2olE20795@devserv.devel.redhat.com>
I've downloaded the latest driver and am running 2.4.20 (yea!) -- the trident.c here
is actually more recent than 2.5.55. It now loads fast and with no protest from
ac97_codec, which has a new ID (ADS114). However, there's still not a peep (I try
cat test.mp3 > /dev/dsp) -- and when KDE Control Center tries to restart the arts
sound server, it alarmingly fails on "CPU overload" or just freezes the whole
system. Is there anything I can do to get more information about what is not
happening?
Cheers,
Peter
Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio, version 0.14.10h,
Enabling device 00:06.0 (0000 -> 0003)
PCI: Assigned IRQ 5 for device 00:06.0
trident: ALi Audio Accelerator found at IO 0x1000, IRQ 5
ac97_codec: AC97 Audio codec, id: ADS114(Unknown)
ac97_codec: AC97 Audio codec, id: ADS114(Unknown)
PCI: Found IRQ 5 for device 00:06.0
gameport0: Acer Laboratories Inc. [ALi] M5451 PCI AC-Link Controller Audio Device at
pci00:06.0 speed 1924 kHz
Quoting Alan Cox <alan@redhat.com>:
> > Trident 4DWave/SiS 7018/ALi 5451,Tvia CyberPro 5050 PCI Audio,
> > version 0.14.9d, 00:57:19 Jan 9 2003
> > PCI: Enabling device 00:06.0 (0000 -> 0003)
> > PCI: Assigned IRQ 10 for device 00:06.0
> > trident: ALi Audio Accelerator found at IO 0x1000, IRQ 10
> > ac97_codec: AC97 Audio codec, id: 0x4144:0x5372 (Unknown)
>
> So far so good.
>
> > ali: AC97 CODEC read timed out.
> > last message repeated 127 times
> > ali: AC97 CODEC write timed out.
> > ac97_codec: AC97 codec, id: 0x0000:0x0000 (Unknown)
>
> Something lost the codec. Could be power management - was the laptop
> suspended before it went funny ?
>
> Alan
>
^ permalink raw reply
* Re: [PATCH] SG_IO ioctl in block layer against lk 2.5.55
From: Jens Axboe @ 2003-01-10 13:06 UTC (permalink / raw)
To: Douglas Gilbert, linux-scsi
In-Reply-To: <3E1EB08D.5060105@torque.net>
On Fri, Jan 10 2003, Douglas Gilbert wrote:
> The attachment modifies the SG_IO ioctl that is in
> the block layer to:
> - convey the SCSI status value back via the sg_io_hdr
> structure
> - in the event of CHECK CONDITION, convey the sense
> buffer back via the sg_io_hdr structure
> - set "output" fields in sg_io_hdr structure to sane
> values
> - modify the errno behaviour to be more like the
> SCSI generic driver's SG_IO ioctl
>
> This patch was presented around lk 2.5.51 but fell between
> the cracks. The only modification is to take account of
> the changes to scsi/scsi_lib.c since then.
Doug,
Patch looks good to me, please feel free to send it to Linus.
--
Jens Axboe
^ permalink raw reply
* Re: Suggestion
From: Mikael Pettersson @ 2003-01-10 13:12 UTC (permalink / raw)
To: Harry Sileoni; +Cc: linux-kernel
In-Reply-To: <1042203152.954.7.camel@vihta>
Harry Sileoni writes:
> While fighting for some time with my Dell Inspiron 8100 laptop and a new
> kernel. No matter what I did in the APM-settings, the computer just
> freezed after some minutes of uptime. Now I noticed a page witch
> informed me that APIC support should not be used. I disabled APIC
> support from the kernel config, and now it works perfect.
>
> So, I suggest you add a line "This option might make your system hang
> randomly" to the APIC support help page, so that other innocent people
> with the same problem don't have to do hours of fighting with the APM,
> which really wasn't the problem as I first though. :)
1. All recent 2.5/2.4 kernels have a blacklist rule that is supposed
to prevent the kernel from enabling the local APIC.
That kernel version are you using? What .config?
Doesn't the kernel boot log contain something like "Dell Inspiron
with broken BIOS detected. Refusing to enable the local APIC"?
2. There is no "APIC support help page" that I know of.
Are you sure you didn't mean ACPI instead? APIC != ACPI but
people keep confusing the two.
^ permalink raw reply
* Re: [patch] R4k cache code synchronization
From: Ralf Baechle @ 2003-01-10 13:03 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux-mips
In-Reply-To: <Pine.GSO.3.96.1030110131859.23678B-100000@delta.ds2.pg.gda.pl>
On Fri, Jan 10, 2003 at 01:37:12PM +0100, Maciej W. Rozycki wrote:
> I can't see any need for flush_cache_l1() and flush_cache_l2(). I'd like
> to remove them. A single flush_cache_all() seems sufficient for our
> needs. Any objections?
The reason for the existance of flush_cache_l1 and flush_cache_l2 is the
Origin. An empty flush_cache_all() is sufficient on the Origin because
it's R10000 processor doesn't suffer from cache aliases. During bootup
we have to flush all caches or the cache coherence logic will send crazy
exceptions at us. For all other occasions just a flush of the primary
caches is sufficient which is why there is flush_cache_l1.
So I think we want to wrap things a bit nicer but basically we have to
keep those cacheops for the sake of the Origin.
Ralf
^ permalink raw reply
* Re: small migration thread fix
From: William Lee Irwin III @ 2003-01-10 13:11 UTC (permalink / raw)
To: Erich Focht; +Cc: Ingo Molnar, Linus Torvalds, linux-kernel, Robert Love
In-Reply-To: <200301101346.03653.efocht@ess.nec.de>
On Fri, Jan 10, 2003 at 01:46:03PM +0100, Erich Focht wrote:
> the small patch fixes a potential problem in the migration thread for
> the case that the first CPU in the cpus_allowed mask of a process is
> offline. Please consider applying it to your trees.
I'm not mingo, but I can say this looks sane. My only question is
whether there are more codepaths that need this kind of check, for
instance, what happens if someone does set_cpus_allowed() to a cpumask
with !(task->cpumask & cpu_online_map) ?
Thanks,
Bill
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: Matthieu Delahaye @ 2003-01-10 12:52 UTC (permalink / raw)
To: jsoe0708; +Cc: Randolph Chung, parisc-linux
In-Reply-To: <3E1AA8D500000877@ocpmta8.freegates.net>
> >
> well I will try to find back the example I encounter (somewhere in jfs-1.0.23
> IIRC)
>
> Cheers,
> Joel
I remind a word access on a table of char at an odd index. Thought it
was reiserFS code.
Matthieu
^ permalink raw reply
* Re: [parisc-linux] ibm-disk on a hp 735/125
From: Joerg Krebs @ 2003-01-10 12:58 UTC (permalink / raw)
To: Nahkola Mikko; +Cc: parisc-linux
In-Reply-To: <20030110124210.GG2160@aurinko.ntc.nokia.com>
Am Fre, 2003-01-10 um 13.42 schrieb Nahkola Mikko:
> On Thu, Jan 09, 2003 at 05:44:31PM +0100, ext Joerg Krebs wrote:
>
> > im running a hp 735/125 with a st31200wd 1GB harddisk, connected to the
> > fast-wide scsi-connector, which run's quit nice.
> > But now I want to replace the disk with a larger 4,3GB ibm dcas-34330
> > disk, but I can't get it be detected by the system, I think i used the
> > same jumper settings as on the old seagate drive.
> > at the search for potential boot devices nothing appears.
>
> I'd say that probably the IBM disk isn't high-voltage. The 735's
> fast-wide is fast-wide-highvoltage-differential, back then they thought
> that no one in their right minds would try to do FWSE and no one had
> thought about LVD yet, or something...
>
Yes you are right, I found the HP 735 Hardware manual on the openpa
Webside and there i found that the wide-scsi connector is just for HVD
Do you know if any HVD disk is detected by the hp or are there just some
special disks for the hp ?
> And IIRC the -wd in the Seagate model code means about that too. I don't
> know about IBM specifically.
>
> > So perhaps someones uses the same harddisk and can tell me the right
> > jumper-settings, the disk itself works fine with a normal PC with a
> > scsi-wide controller.
>
> Well, if it works in a normal PC, that usually means that it isn't HVD. I
> only know of two HVD adapters for PCs, Adaptec AHA-1744 and 2944, and
> those were always expensive ...
>
> I suppose you could get the disk to work on a single-ended interface or
> get an appropriate EISA card.
>
> Besides, do you mean that the 735 FWD interface works in Linux/parisc
> nowadays? Great...
>
No linux/parisc isn`t working with FWD , I suppose, I run my HP still
under HP-UX, i have another hp 735/99 on which I want to install linux
on it, but there i have se disks in it, for now I'm running linux/parisc
only on a 715/75 with an older version of linux/parisc (the one without
hil mouse support)
Thanks for your help
J.Krebs
>
> --
> Mikko Nahkola <mikko.nahkola@nokia.com>
> Tre-IN sysadmin <mnahkola@trein.ntc.nokia.com>
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/mailman/listinfo/parisc-linux
>
--
''~``
( o o )
+------------------.oooO--(_)--Oooo.------------------+
| |
| .oooO |
| ( ) Oooo. |
+---------------------\ (----( )--------------------+
Joerg Krebs \_) ) /
Oettingenstr. 67 (_/
80538 Muenchen
Raum: Z1.16
Tel.: +49-89-2180-9251
Fax.: +49-89-2180-9202
Homepage:
http://www.bmo.physik.uni-muenchen.de/~krebs
------------------------------------------------JK
^ permalink raw reply
* Re: [parisc-linux] pa-risc 64 compilation
From: Matthew Wilcox @ 2003-01-10 12:57 UTC (permalink / raw)
To: FARINATI,LEANDRO (HP-Brazil,ex1); +Cc: Parisc-Linux List (E-mail)
In-Reply-To: <9A0482A7BD2506488AD9417C93F3714F0105349E@xsp01.brazil.hp.com>
On Thu, Jan 09, 2003 at 12:52:18PM -0500, FARINATI,LEANDRO (HP-Brazil,ex1) wrote:
> I have a problem to compile an 64 kernel in an 64 machine. The
> problem is: hppa64-linux-gcc compiler not found. Someone know what happened?
> Where I find this gcc version?
Add http://ftp.parisc-linux.org/unofficial-debs/ to your
/etc/apt/sources.list and apt-get install gcc-hppa64.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: Andre Hedrick @ 2003-01-10 13:03 UTC (permalink / raw)
To: Alan Cox; +Cc: fverscheure, Linux Kernel Mailing List, Marcelo Tosatti
In-Reply-To: <1042205732.28469.89.camel@irongate.swansea.linux.org.uk>
Oh, just let the darn thing barf a 0x51/0x04 is fine with me!
Just an abort/unsupported command.
Cheers,
On 10 Jan 2003, Alan Cox wrote:
> On Fri, 2003-01-10 at 11:14, Andre Hedrick wrote:
> > The drive does random and automatic flush caches, if an error happens it
> > does not report. *sigh* When APM hits it with a flush and pray the error
> > is from this flush, but it does not matter ... the kernel does not have
> > the paths to deal this issue ... so bye bye data! Now it if the current
> > flush is not the owner of the error OMFG is suggested.
>
> For that matter the BIOS tends to issue the flush, in fact APM is
> supposed to be transparent so the BIOS is required to handle it and
> since a critical shutdown from the APM PM might not even hit the OS
> it has to. Of course pigs also fly 8)
>
> > > > I had a look at patch 2.4.21pre3 and the code looks the same.
> > > >
> > > > And by the way how are powered off the IDE drives ?
> > > > Because a FLUSH CACHE or STANDY or SLEEP is MANDATORY before powering off the
> > > > drive with cache enabled or you will enjoy lost data
> > >
> > > IDE disagrees with itself over this but when we get a controlled power
> > > off we do this. The same ATA5/ATA6 problem may well be present there
> > > too. I will review both
> >
> > Not true, the firmware knows to commit the data to platter.
> > If it was true you would be screaming long ago.
>
> IDE disagrees with itself because it is meant to work compatibly but if
> you run it compatibly you lose data on poweroff.
>
> >
> > > Any specific opinion Andre ?
> >
> > A dirty trick used to date is to pop the STANDY or SLEEP, and depend on
> > the drive to deal with the double dirty flush error. If the FLUSH CACHE
> > was not valid, the drive would spin back up from STANDY, but not from
> > SLEEP, this could be a problem. However SLEEP issued by the driver only
> > happens at shutdown unless it has been changed. In the shutdown process,
> > each partition unmount was flushed and also once extra when the usage
> > count was set to zero. Worst case was 2 flush min.
> >
>
> The original question however is whether we are skipping issuing the flush
> and sleep on ATA3-5 devices when we should not, because the test is over
> strong.
>
> It seems weakening the test is the best option, it fixes ATA-5 and any device
> told to sleep, standby or flush that doesn't know the command is just going
> to go "Huh ?" and we'll get a nice easy to handle error.
>
> Alan
>
>
Andre Hedrick
LAD Storage Consulting Group
^ permalink raw reply
* Re: [PATCH]Re: spin_locks without smp.
From: William Lee Irwin III @ 2003-01-10 13:04 UTC (permalink / raw)
To: Alan Cox; +Cc: Maciej Soltysiak, Linux Kernel Mailing List
In-Reply-To: <1042204846.28469.75.camel@irongate.swansea.linux.org.uk>
On Fri, 2003-01-10 at 12:09, Maciej Soltysiak wrote:
>> Yes sir. :)
>> Is that okay?
On Fri, Jan 10, 2003 at 01:20:48PM +0000, Alan Cox wrote:
> I'm not convinced its the right way. The driver does the things it
> does in order
> to keep performance acceptable. eexpress, 8390 and one or two other
> drivers have a paticular problem that is hard to handle with our current
> locks (and which at the time Linus made a decision wasn't a good thing
> to try and handle generically).
> We have to ensure that the IRQ path doesn't execute in parallel with
> the transmit/timeout path. At the same time the packet upload to the
> card is extremely slow. Sufficiently slow in fact that serial ports
> just stop working when you use it without the ifdef paths.
> On uniprocessor systems even with pre-empt the IRQ handler cannot be
> pre-empted by normal code execution. On SMP they can run across two
> processors. What the disable_irq path is doing for uniprocessor is
> implementing
Okay, what I'm getting here is that the UP case already has preempt
disabled b/c the locks are taken in IRQ context?
The thing I don't get is how the spinlock bits cause horrendous
timing issues on UP that are different from SMP, esp. b/c they are
#ifdef'd elsewhere to do nothing but inc/dec preempt_count elsewhere.
There's a bit of "how did it happen" missing in my mind at least.
On Fri, Jan 10, 2003 at 01:20:48PM +0000, Alan Cox wrote:
> spin_lock_irqsavesomeirqsonly()
> and on the kind of boxes that have these old cards its pretty important
> to keep this.
> I would argue that if we have an IRQ disabled we should forbid pre-empt.
> If an IRQ is disabled and we pre-empt to a task that needs to allocate
> memory and we swap to a device on that IRQ we may deadlock.
> So the fix is either to make disable_irq()/enable_irq() correctly
> adjust the pre-empt restrictions, which is actually quite hard to see
> how to do right as the disable/enable may be in different tasks, or to
> change the code to do the following
> preempt_disable()
> disable_irq()
> #ifdef CONFIG_SMP
> spin_lock_...
> #endif
Hmm, the part I'm missing here is why folding the preempt_disable()
into the spin_lock() is wrong. Or is it the implicit local_irq_save()
that's the (massive performance) problem?
On Fri, Jan 10, 2003 at 01:20:48PM +0000, Alan Cox wrote:
> Note that we must disable the irq before taking the spinlock or we
> have another deadlock with our irq path versus disable_irq waiting
> for the IRQ completion before returning.
> If my analysis of the disable_irq versus pre-empt and memory allocation
> deadlock is correct we have some other cases we need to address too.
Hmm, this is tricky, since it's really disabling interrupts for too
long to make progress on UP; I suspect this issue might have _some_
(negative) impact on SMP, but how much (or for how many relevant
systems) I'm not sure.
Some serious thought may need to go into this, but it's very far afield
for me. I think some ppl more directly involved with these issues
(rml, mingo, others???) might need to get flagged down to fix it for
legacy systems (presumably modern ones won't have the issue at all)
for 2.7.x etc. if it really does matter.
I'm tied up with 64GB at the moment so my wetware cpu cycles are really
totally unavailable for this. =(
Thanks,
Bill
^ permalink raw reply
* Re: ACPI problems on Athlon MP system
From: Ducrot Bruno @ 2003-01-10 12:46 UTC (permalink / raw)
To: Martin Siegert; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20030110030741.GA2580-0ze2hujOWYhqr3d4nwidZ7Dks+cytr/Z@public.gmane.org>
On Thu, Jan 09, 2003 at 07:07:41PM -0800, Martin Siegert wrote:
> Hi,
>
> I am not sure whether this is the correct place to ask this question,
> but hopefully you can point me in the right direction.
>
...
> The machine has ACPI enabled in the bios. When I compile the kernel
> with ACPI disabled, the poweroff command shuts down the system, but
> does not shut off the power (it acts exactly like the halt command).
> In order to shutoff the machine I must press the power switch.
>
> When I compile the kernel with ACPI enabled the situation is worse:
> the halt and poweroff commands still work in exactly the same way
> (shutdown the system), but now I cannot switch off the machine
> anymore: pressing the power switch has absolutely no effect
> (regardless of how long I hold the switch). The only way to
ACPI spec require that holding the power switch for 4 second will
switch off the system in *any* case as an emergency power down.
Those if really you can not power down your machine this way,
this is more likely an hardware trouble.
BTW, have you tried the latest ACPI patch on sf.net?
--
Ducrot Bruno
-- Which is worse: ignorance or apathy?
-- Don't know. Don't care.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ 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.