* device interface api
From: Martin Waitz @ 2002-12-18 0:40 UTC (permalink / raw)
To: Patrick Mochel; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]
hi :)
please have a look at interface_add_data:
int interface_add_data(struct intf_data * data)
{
struct device_interface * intf = intf_from_data(data);
data->intf_num = data->intf->devnum++;
data->kobj.subsys = &intf->subsys;
kobject_register(&data->kobj);
[...]
data->kobj.subsys is initialized here, but intf_from_data
is using this data->kobj.subsys to get intf, instead of data->intf.
do you want to remove data->intf?
either way, interface_add_data should change.
are interface users supposed to set data->intf or data->kobj.subsys?
another small glitch i noticed while diggin in the code:
================================================================
--- linux-2.5/lib/kobject.c Tue Dec 10 12:59:02 2002
+++ linux/lib/kobject.c Tue Dec 17 13:15:19 2002
@@ -218,7 +218,7 @@ int subsystem_register(struct subsystem
s->kobj.parent = &s->parent->kobj;
pr_debug("subsystem %s: registering, parent: %s\n",
s->kobj.name,s->parent ? s->parent->kobj.name : "<none>");
- return kobject_register(&s->kobj);
+ return kobject_add(&s->kobj);
}
void subsystem_unregister(struct subsystem * s)
================================================================
subsystem_register first calls subsystem_init, which already
does kobject_init, so a full kobject_register is not needed
(and is in fact bad, as it again increases the refcounter for kobj.subsys)
--
CU, / Friedrich-Alexander University Erlangen, Germany
Martin Waitz // [Tali on IRCnet] [tali.home.pages.de] _________
______________/// - - - - - - - - - - - - - - - - - - - - ///
dies ist eine manuell generierte mail, sie beinhaltet //
tippfehler und ist auch ohne grossbuchstaben gueltig. /
-
Wer bereit ist, grundlegende Freiheiten aufzugeben, um sich
kurzfristige Sicherheit zu verschaffen, der hat weder Freiheit
noch Sicherheit verdient.
Benjamin Franklin (1706 - 1790)
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Ulrich Drepper @ 2002-12-18 0:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Alan Cox, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212171619230.1578-100000@home.transmeta.com>
Linus Torvalds wrote:
> No, the way sysenter works, the table approach just sucks up dcache space
> (the kernel cannot know which sysenter is the one that the user uses
> anyway, so the jump table would have to just add back some index and we'd
> be back exactly where we started)
>
> I'll keep it the way it is now.
I won't argue since honestly, not doing it is much easier for me. But I
want to be sure I'm clear.
What I suggested is to have the first part of the global page be
.p2align 3
jmp sysenter_label
.p2align 3
jmp sysenter_label
...
.p2align
jmp userlevel_gettimeofday
sysenter_label:
the usual sysenter code
userlevel_gettimeofday:
whatever necessary
All this would be in the global page. There is only one sysenter call.
--
--------------. ,-. 444 Castro Street
Ulrich Drepper \ ,-----------------' \ Mountain View, CA 94041 USA
Red Hat `--' drepper at redhat.com `---------------------------
^ permalink raw reply
* Re: Domain transition -- enabling user_r in eklogin
From: forrest whitcher @ 2002-12-18 0:28 UTC (permalink / raw)
To: Stephen D. Smalley; +Cc: SELinux
In-Reply-To: <200212171725.MAA01304@moss-shockers.ncsc.mil>
On Tue, 17 Dec 2002 12:25:33 -0500 (EST)
"Stephen D. Smalley" <sds@epoch.ncsc.mil> did inscribe thusly:
>
> This looks like you aren't using the SELinux-patched login program.
> The login process needs to set the security context for the user session
> and to relabel the tty based on that security context. If you use an
> unmodified login, you'll get the behavior above.
>
Ahh thanks! that was indeed it, darned if I can figure out why /bin/login
wasn't correctly replaced in the 'make install', but anyhow once login
and login.krb5 are replaced with the patched version, yes all works
nicely.
I'll look into adding kerberos auth to newrole(1) to save retypings of
password next.
forrest
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply
* Re: NFS - IRIX client issues
From: Orion Poplawski @ 2002-12-18 0:28 UTC (permalink / raw)
To: Samuel Flory; +Cc: linux-kernel
In-Reply-To: <3DEE95D0.9010706@rackable.com>
Samuel Flory wrote:
> Orion Poplawski wrote:
>
>>>
>> The mount comes up fine and works for quite a while and then crashes.
>> This is under relatively heavy load (tar files being unpacked, data
>> files manipulated, etc.). No iptables/chains.
>>
>> The mount is automounted, the resulting mtab entry on IRIX is:
>
>
>
> Are you using amd or autofs? Does it occur when you manually mount
> the share? "mount lego:/export/turb3 /data/turb3"
>
Followup: We changed the nfs mount options to mount with NFSv2 and have
not been able to reproduce the problem, yet.
^ permalink raw reply
* [patch] MSNDCLAS_HAVE_BOOT and MSNDPIN_HAVE_BOOT shouldn't ask questions
From: Adrian Bunk @ 2002-12-18 0:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel
Hi Linus,
2.5.50 included a change from -ac which changed MSNDCLAS_HAVE_BOOT and
MSNDPIN_HAVE_BOOT to asked questions. This is wrong (I know since I was
the one who wrote the patch Alan picked up...).
They shouldn't ask questions, the following patch reverts my buggy
change:
--- linux-2.5.50/sound/oss/Kconfig.old 2002-11-30 20:47:01.000000000 +0100
+++ linux-2.5.50/sound/oss/Kconfig 2002-11-30 20:47:25.000000000 +0100
@@ -293,7 +293,7 @@
depends on SOUND_PRIME && SOUND_MSNDCLAS=y
config MSNDCLAS_HAVE_BOOT
- bool "Have MSNDINIT.BIN firmware file"
+ bool
depends on SOUND_MSNDCLAS=y
default y
@@ -355,7 +355,7 @@
depends on SOUND_PRIME && SOUND_MSNDPIN=y
config MSNDPIN_HAVE_BOOT
- bool "Have PNDSPINI.BIN firmware file"
+ bool
depends on SOUND_MSNDPIN=y
default y
Please apply
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply
* Re: lsscsi for lk 2.5.51
From: Douglas Gilbert @ 2002-12-18 0:13 UTC (permalink / raw)
To: dougg; +Cc: linux-scsi, patmans
In-Reply-To: <3DFBE00B.1070805@torque.net>
Done a bit more work on lsscsi:
- entries now sorted by host,channel,id,lun tuple
- "classic" option ('-c') that outputs just like
'cat /proc/scsi/scsi'
- added a few more switches and fixed some bugs.
There is a small web page at:
http://www.torque.net/scsi/lsscsi.html
On it there are links to a tarball, binary and source rpms.
Doug Gilbert
Douglas Gilbert wrote:
> Since sysfs now contains a reasonable amount of data about
> scsi devices, it is possible to write an application
> that scans this information and presents it in a "ls"
> form (akin to lspci and lsusb).
>
> Attached is a toy program called lsssci that could
> grow into something more useful. It requires lk 2.5.51
> or later.
>
> $ lsscsi
> [4:0:0:0] CDROM CREATIVE CD5233E 1.00 /dev/sr0
> [3:0:0:0] disk Linux scsi_debug 0004 /dev/sdb
> [2:0:6:0] tape SONY SDT-7000 0192
> [0:0:8:0] disk FUJITSU MAM3184MP 0105 /dev/sda
>
>
> This output corresponds to my system which has these "scsi"
> devices:
>
> $ cat /proc/scsi/scsi
> Attached devices:
> Host: scsi0 Channel: 00 Id: 08 Lun: 00
> Vendor: FUJITSU Model: MAM3184MP Rev: 0105
> Type: Direct-Access ANSI SCSI revision: 03
> Host: scsi2 Channel: 00 Id: 06 Lun: 00
> Vendor: SONY Model: SDT-7000 Rev: 0192
> Type: Sequential-Access ANSI SCSI revision: 02
> Host: scsi3 Channel: 00 Id: 00 Lun: 00
> Vendor: Linux Model: scsi_debug Rev: 0004
> Type: Direct-Access ANSI SCSI revision: 03
> Host: scsi4 Channel: 00 Id: 00 Lun: 00
> Vendor: CREATIVE Model: CD5233E Rev: 1.00
> Type: CD-ROM ANSI SCSI revision: 02
>
>
> sysfs doesn't provide the ANSI SCSI revision number associated
> with each device (hopefully Pat can add that in the future).
> Otherwise, all the information that /proc/scsi/scsi uses 3
> lines per device for, can be compressed onto one line. Putting
> the device node (e.g. /dev/sda) seems a useful addition.
> [That latter addition is only done currently for block scsi
> devices (hence it doesn't appear for the tape).]
>
> Doug Gilbert
^ permalink raw reply
* Re: MIPS64 kernel cross-compiling
From: Ralf Baechle @ 2002-12-18 0:11 UTC (permalink / raw)
To: Julian Scheel; +Cc: linux-mips
In-Reply-To: <200212172100.27296.jscheel@activevb.de>
On Tue, Dec 17, 2002 at 09:00:27PM +0100, Julian Scheel wrote:
> From: Julian Scheel <jscheel@activevb.de>
> To: linux-mips@linux-mips.org
> Subject: MIPS64 kernel cross-compiling
> Date: Tue, 17 Dec 2002 21:00:27 +0100
> Content-Type: text/plain;
> charset="iso-8859-15"
>
> Hi,
>
> we're trying to compile a kernel for an embedded system with a
> MIPS64-processor on it.
> We tried first with your CVS-sources, but there we get this error:
>
> -----
> Generating include/linux/version.h (unchanged)
> make[1]: Nothing to be done for `__build'.
> SPLIT include/linux/autoconf.h -> include/config/*
> make -f scripts/Makefile.build obj=arch/mips64/kernel
> arch/mips64/kernel/offset.s
> make[1]: `arch/mips64/kernel/offset.s' is up to date.
> /bin/sh: arch/mips64/kernel/offset.s: Datei oder Verzeichnis nicht gefunden
> -----
2.5. Don't dream about using it current. Use the linux_2_4 branch.
Ralf
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Linus Torvalds @ 2002-12-18 0:20 UTC (permalink / raw)
To: Ulrich Drepper
Cc: H. Peter Anvin, Alan Cox, Matti Aarnio, Hugh Dickins, Dave Jones,
Ingo Molnar, Linux Kernel Mailing List
In-Reply-To: <3DFF83C5.6000007@redhat.com>
On Tue, 17 Dec 2002, Ulrich Drepper wrote:
>
> This is why I'd say mkae no distinction at all. Have the first
> nr_syscalls * 8 bytes starting at 0xfffff000 as a jump table.
No, the way sysenter works, the table approach just sucks up dcache space
(the kernel cannot know which sysenter is the one that the user uses
anyway, so the jump table would have to just add back some index and we'd
be back exactly where we started)
I'll keep it the way it is now.
Linus
^ permalink raw reply
* Re: [patch] ext3 deadlock fix
From: Pierre Lombard @ 2002-12-18 0:16 UTC (permalink / raw)
To: Andrew Morton; +Cc: lkml
In-Reply-To: <3DFCE535.3417CEDB@digeo.com>
Hi,
* Andrew Morton <akpm@digeo.com> [2002-12-15 21:27]:
> The patch ensures that ->sync_fs is never run under lock_super().
> --- 24/Documentation/filesystems/Locking~sync_fs-fix Sun Dec 15 11:12:48 2002
> +++ 24-akpm/Documentation/filesystems/Locking Sun Dec 15 11:16:15 2002
> @@ -93,6 +93,7 @@ prototypes:
> void (*delete_inode) (struct inode *);
> void (*put_super) (struct super_block *);
> void (*write_super) (struct super_block *);
> + int (*sync_fs) (struct super_block *);
> int (*statfs) (struct super_block *, struct statfs *);
> int (*remount_fs) (struct super_block *, int *, char *);
> void (*clear_inode) (struct inode *);
> @@ -108,6 +109,7 @@ delete_inode: no
> clear_inode: no
> put_super: yes yes maybe (see below)
> write_super: yes yes maybe (see below)
> +write_super: yes no maybe (see below)
~~~~~~~~~~~
A small typo in the documentation.
> statfs: yes no no
> remount_fs: yes yes maybe (see below)
> umount_begin: yes no maybe (see below)
--
Best regards,
Pierre
^ permalink raw reply
* Sequencer Input
From: Brian Victor @ 2002-12-18 0:06 UTC (permalink / raw)
To: alsa-devel
I'm using a MidiSport 1x1 and devfs. The modules are loading, pmidi is
displaying the MidiSport and playing MIDI files through it just fine, so
I presume output through /dev/snd/seq is working. cat /dev/snd/midiC0D0
displays approrpriate "garbage" characters, but cat /dev/snd/seq does
nothing, and the seqdemo.c sample just sits there. What do I need to do
to get this working? This is with RC6.
Relevant modules:
snd-seq-midi 3136 0 (autoclean)
snd-seq-oss 23456 0 (unused)
snd-seq-midi-event 3240 0 [snd-seq-midi snd-seq-oss]
snd-seq 39312 2 [snd-seq-midi snd-seq-oss snd-seq-midi-event]
usb-ohci 18088 0 (unused)
snd-usb-audio 32704 0
snd-pcm 58304 0 [snd-usb-audio]
snd-timer 11080 0 [snd-seq snd-pcm]
snd-rawmidi 12800 0 [snd-seq-midi snd-usb-audio]
snd-seq-device 3776 0 [snd-seq-midi snd-seq-oss snd-seq snd-rawmidi]
snd 27020 0 [snd-seq-midi snd-seq-oss snd-seq-midi-event
snd-seq snd-usb-audio snd-pcm snd-timer snd-rawmidi snd-seq-device]
soundcore 3908 4 [snd]
Thanks,
--
Brian
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: Compile warnings due to missing __inline__ in fs/xfs/xfs_log.h
From: Thomas Schlichter @ 2002-12-18 0:05 UTC (permalink / raw)
To: Stephen Lord; +Cc: Linux Kernel Mailing List
In-Reply-To: <1040147719.1368.424.camel@localhost.localdomain>
OK, thanks for that info, now I understand...
So I think I better take the warnings ;-)
Thomas
Am Dienstag, 17. Dezember 2002 18:55 schrieb Stephen Lord:
> On Tue, 2002-12-17 at 10:01, Thomas Schlichter wrote:
> > As the __inline__ directive in front of the _lsn_cmp function is not used
> > with the gcc version 2.95.x, compile-warnings result from many files
> > including this header-file.
>
> The reason inline is turned off for this compiler version is that it
> generates bad code when inlining this code. So you can have a quiet
> compile, or bad code.
>
> Steve
^ permalink raw reply
* Re: [Linux-ia64] RTC support on ia64
From: David Mosberger @ 2002-12-17 23:57 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805600@msgid-missing>
>>>>> On Tue, 17 Dec 2002 17:26:10 +0100 (NFT), Joel GUILLET <Joel.Guillet@bull.net> said:
Joel> This can be used for example to run scheduler latencies tests
Joel> (a way of using amlat) - I've got some more stuff for this,
Joel> please mail me.
What's wrong with using the PMU for this? That's something that works
on all ia64 platforms and doesn't depend on legacy hardware.
--david
^ permalink raw reply
* Re: [Linux-ia64] Strange ACPI interruptions in 2.5.45 kernel
From: David Mosberger @ 2002-12-17 23:55 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805599@msgid-missing>
>>>>> On Tue, 17 Dec 2002 16:21:46 +0100 (NFT), Joel GUILLET <Joel.Guillet@bull.net> said:
Joel> I'm working on a Lion machine (with 2 processors Itanium I)
Joel> running a 2.5.45 kernel, and I've got thousands of
Joel> interruptions routed throw ACPI.
Joel> I use PS/2 mouse and keyboard. I've seen there were lots of
Joel> problems with PS/2 on 2.5-ia64 kernels but I didn't see anyone
Joel> who had this one.
Joel> When I say "lots" of interruptions, I mean about 80 times more
Joel> than the timer ticks !!!! So, one of my processor spend almost
Joel> all his time dealing with ACPI interruptions .
Joel> Just to have a look, I've tried to disable ACPI interruptions
Joel> after the boot. ...and now, the interruptions are reported via
Joel> one of the serial irq (according to the /proc/interrupts).. if
Joel> it can help.
Joel> I had no problems with this interruptions in the 2.5.44 kernel
Joel> or previous versions. I searched the code to see what had
Joel> changed between the 2 kernels, but I couldn't find any
Joel> interesting explanation. BUT I already had problems since the
Joel> 2.5 kernels(like a lot of people) with my mouse or/and my
Joel> keyboard (with i8042).
Joel> So if you have any idea...?
That doesn't ring a bell. I suppose you could try 2.5.50. I don't
use the Lion's for kernel development very often myself anymore
because they're diffiult and slow to remote-reboot. Perhaps someone
else can help.
--david
^ permalink raw reply
* Re: compute_return_epc
From: Ralf Baechle @ 2002-12-17 23:50 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: linux-mips
In-Reply-To: <Pine.GSO.3.96.1021217145149.7289B-100000@delta.ds2.pg.gda.pl>
On Tue, Dec 17, 2002 at 02:54:45PM +0100, Maciej W. Rozycki wrote:
> > So I'd like to apply the following patch which limits the use of
> > compute_return_epc to those cases where we actually did some sort of
> > instruction emulation. Comments?
>
> Ah, finally! Thanks for offloading the task from me. ;-)
Wonderful :-)
Ralf
^ permalink raw reply
* Re: lk maintainers
From: Zwane Mwaikambo @ 2002-12-17 23:55 UTC (permalink / raw)
To: Denis Vlasenko; +Cc: linux-kernel
In-Reply-To: <200212170628.gBH6Scs15943@Port.imtp.ilyichevsk.odessa.ua>
On Tue, 17 Dec 2002, Denis Vlasenko wrote:
> Martin Dalecki <martin@dalecki.de> [11 mar 2002]
> IDE subsystem maintainer for 2.5
> (mail Vojtech Pavlik <vojtech@suse.cz> too)
Should this entry still be there?
> Eric S. Raymond <esr@thyrsus.com> [5 feb 2002]
> Send kernel configuration bug reports and suggestions to me.
> Also I'll be more than happy to accept help enties for kernel config
> options (Configure.help).
Can't say i've seen this fellow in a while either.
Zwane
--
function.linuxpower.ca
^ permalink raw reply
* [2.4.21-pre1] scx200.c in arch/i386/kernel
From: Jörg Prante @ 2002-12-17 23:51 UTC (permalink / raw)
To: linux-kernel; +Cc: wingel
Hi,
I just compiled 2.4.21-pre1 for a consistency check with all configure options
set to 'y' and found a file arch/i386/kernel/scx200.c which does not compile
because of missing support in the Makefile. It is introduced by the
2.4.21-pre1 patch by Marcelo.
Is there a reason why it's in the kernel directory of the i386 architecture?
This is a very unusual place.
I moved it to drivers/char/scx200.c and it compiles like a charme, after
correcting the Makefiles. Is there any chance of moving it to from the arch
directory to a more appropriate place? Or did I misunderstand?
I don't know the scx200 Nat Sem chips, I don't have one and I don't even care,
it's just because I'm doing some thorough build checks on my new -jp kernel
patch set.
Best regards,
Jörg
^ permalink raw reply
* Re: Unaligned Instruction Trap
From: Ralf Baechle @ 2002-12-17 23:41 UTC (permalink / raw)
To: David D. McCoach; +Cc: linux-mips
In-Reply-To: <016401c2a5fb$0d636fb0$8b01a8c0@wmiddm>
On Tue, Dec 17, 2002 at 01:35:19PM -0500, David D. McCoach wrote:
> I have a problem with random "Unaligned Instruction Traps: during the boot
> process. After rcS starts executing.
> I am using as Flash file system through a MTD driver.
> Does anyone have a thread for me pull on?
Not really. The exception you're getting is really just the sympthom.
The actual problem is somewhere else ...
Ralf
^ permalink raw reply
* Re: Pre-emptive kernel for MIPs 32
From: Ralf Baechle @ 2002-12-17 23:39 UTC (permalink / raw)
To: Marcus.Jones; +Cc: linux-mips
In-Reply-To: <OF5C4D3FBD.1018D485-ON80256C92.005EC5E1@zarlink.com>
On Tue, Dec 17, 2002 at 05:22:36PM +0000, Marcus.Jones@Zarlink.Com wrote:
> Is anyone using the pre-emptive kernel option on the Linux MIPs kernel.
> Could you recommend a CVS tag to use for a reasonably stable version?
There is no stable that is 2.4 kernel with preemption support in CVS,
so you need to get the preemption patch from somewhere else.
Ralf
^ permalink raw reply
* Re: 2.5.52 compile error
From: eric lin @ 2002-12-18 7:46 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.33L2.0212171527070.17648-100000@dragon.pdx.osdl.net>
>
> Just remove io_daemon.o from the fs/intermezzo/Makefile .
>
Thanks your point out, it pass this problem at compile time, then it
still terminate by another error
gcc -Wp,-MD,drivers/block/.ps2esdi.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686 -Iarch/i386/mach-generic
-fomit-frame-pointer -nostdinc -iwithprefix include -DMODULE
-DKBUILD_BASENAME=ps2esdi -DKBUILD_MODNAME=ps2esdi -c -o
drivers/block/ps2esdi.o drivers/block/ps2esdi.c
drivers/block/ps2esdi.c:185: redefinition of `__initfn'
drivers/block/ps2esdi.c:171: `__initfn' previously defined here
drivers/block/ps2esdi.c: In function `__initfn':
drivers/block/ps2esdi.c:189: warning: initialization from incompatible
pointer type
drivers/block/ps2esdi.c:192: dereferencing pointer to incomplete type
drivers/block/ps2esdi.c:192: dereferencing pointer to incomplete type
drivers/block/ps2esdi.c:193: dereferencing pointer to incomplete type
drivers/block/ps2esdi.c:196: dereferencing pointer to incomplete type
drivers/block/ps2esdi.c:197: dereferencing pointer to incomplete type
drivers/block/ps2esdi.c:199: dereferencing pointer to incomplete type
drivers/block/ps2esdi.c: In function `__exitfn':
drivers/block/ps2esdi.c:207: warning: implicit declaration of function
`mca_mark_as_unused'
drivers/block/ps2esdi.c:215: `i' undeclared (first use in this function)
drivers/block/ps2esdi.c:215: (Each undeclared identifier is reported
only once
drivers/block/ps2esdi.c:215: for each function it appears in.)
drivers/block/ps2esdi.c: In function `ps2esdi_geninit':
drivers/block/ps2esdi.c:298: warning: implicit declaration of function
`mca_find_adapter'
drivers/block/ps2esdi.c:298: `MCA_NOTFOUND' undeclared (first use in
this function)
drivers/block/ps2esdi.c:309: warning: implicit declaration of function
`mca_set_adapter_name'
drivers/block/ps2esdi.c:315: warning: implicit declaration of function
`mca_mark_as_used'
drivers/block/ps2esdi.c:316: warning: passing arg 2 of
`mca_set_adapter_procfn' from incompatible pointer type
drivers/block/ps2esdi.c:333: warning: implicit declaration of function
`mca_read_stored_pos'
drivers/block/ps2esdi.c: In function `do_ps2esdi_request':
drivers/block/ps2esdi.c:508: warning: long long unsigned int format,
different type arg (arg 3)
{standard input}: Assembler messages:
{standard input}:216: Error: symbol `__initfn' is already defined
make[2]: *** [drivers/block/ps2esdi.o] Error 1
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2
highly appreciate any advancer's advice
--
Sincere Eric
www.linuxspice.com
linux pc for sale
^ permalink raw reply
* Re: 405LP compile fix
From: Hollis Blanchard @ 2002-12-17 23:31 UTC (permalink / raw)
To: embedded list
In-Reply-To: <1040154588.1100.171.camel@granite.austin.ibm.com>
On Tue, 2002-12-17 at 13:49, Hollis Blanchard wrote:
>
> This patch fixes the Beech build, which is calling the now-nonexistant
> function beech_time_init. In actuality beech_time_init was never called
> anyways... :)
Oops, I meant to say "beech_calibrate_decr was never called anyways",
but you knew what I meant...
-Hollis
--
PowerPC Linux
IBM Linux Technology Center
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: 2.5.52 compile error
From: Randy.Dunlap @ 2002-12-17 23:28 UTC (permalink / raw)
To: eric lin; +Cc: Bob Miller, linux-kernel
In-Reply-To: <3E00231C.8020702@centurytel.net>
On Wed, 18 Dec 2002, eric lin wrote:
| in the Input device suppoort
| I did not see Config_inout in make menuconfig, so I suppose is first
| item(if I am wrong please notify me)
It's "Input device support", immediately after Telephony Support
and just before Character devices.
| them make dep, meke clean, make modules
| then it terminate some other error
|
| gcc -Wp,-MD,fs/intermezzo/.inode.o.d -D__KERNEL__ -Iinclude -Wall
| -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
| -pipe -mpreferred-stack-boundary=2 -march=i686 -Iarch/i386/mach-generic
| -fomit-frame-pointer -nostdinc -iwithprefix include -DMODULE
| -DKBUILD_BASENAME=inode -DKBUILD_MODNAME=intermezzo -c -o
| fs/intermezzo/inode.o fs/intermezzo/inode.c
| make[2]: *** No rule to make target `fs/intermezzo/io_daemon.s', needed
| by `fs/intermezzo/io_daemon.o'. Stop.
| make[1]: *** [fs/intermezzo] Error 2
| make: *** [fs] Error 2
Just remove io_daemon.o from the fs/intermezzo/Makefile .
--
~Randy
^ permalink raw reply
* [Linux-ia64] Re: Use of __ia64_syscall() - syscall interface
From: David Mosberger @ 2002-12-17 23:25 UTC (permalink / raw)
To: linux-ia64
In-Reply-To: <marc-linux-ia64-105590709805572@msgid-missing>
>>>>> On Tue, 17 Dec 2002 15:00:49 +0100 (NFT), Joel GUILLET <Joel.Guillet@bull.net> said:
Joel> Actually, I had seen before some (lots of) mails (many from
Joel> you) that recommands the use of the syscall() interface, but I
Joel> mis-understood the message... The problem is that I got some
Joel> problems to find documentation about this interface and made a
Joel> mix between the kernel and the glibc interfaces. (I finally
Joel> found some in glibc/manual/libc.info-43 )
Yes, syscall() is documented in the glibc manual.
Joel> #ifndef __NR_sched_setaffinity
Joel> #ifndef _AFFINITY_H
Joel> #define _AFFINITY_H
Joel> #if defined(__ia64__)
Joel> #define __NR_sched_setaffinity 1231
Joel> #define __NR_sched_getaffinity 1232
Joel> #endif
Joel> #define sched_setaffinity(arg1, arg2, arg3) syscall(__NR_sched_setaffinity, arg1, arg2, arg3)
Joel> #define sched_getaffinity(arg1, arg2, arg3) syscall(__NR_sched_getaffinity, arg1, arg2, arg3)
Joel> #endif /* __NR_sched_setaffinity */
Joel> #endif /* _AFFINITY_H */
This is basically fine, except that for syscall(), the syscall number macros
by convention start with SYS_*. So I'd rewrite your code to:
#ifndef SYS_sched_setaffinity
#ifndef _AFFINITY_H
#define _AFFINITY_H
#if defined(__ia64__)
#define SYS_sched_setaffinity 1231
#define SYS_sched_getaffinity 1232
#endif
#define sched_setaffinity(arg1, arg2, arg3) syscall(SYS_sched_setaffinity, arg1, arg2, arg3)
#define sched_getaffinity(arg1, arg2, arg3) syscall(SYS_sched_getaffinity, arg1, arg2, arg3)
#endif /* SYS_sched_setaffinity */
#endif /* _AFFINITY_H */
--david
^ permalink raw reply
* Re: 2.5.52 compile error
From: eric lin @ 2002-12-18 7:26 UTC (permalink / raw)
To: Bob Miller; +Cc: linux-kernel
In-Reply-To: <20021217225428.GC1069@doc.pdx.osdl.net>
in the Input device suppoort
I did not see Config_inout in make menuconfig, so I suppose is first
item(if I am wrong please notify me)
them make dep, meke clean, make modules
then it terminate some other error
gcc -Wp,-MD,fs/intermezzo/.inode.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686 -Iarch/i386/mach-generic
-fomit-frame-pointer -nostdinc -iwithprefix include -DMODULE
-DKBUILD_BASENAME=inode -DKBUILD_MODNAME=intermezzo -c -o
fs/intermezzo/inode.o fs/intermezzo/inode.c
make[2]: *** No rule to make target `fs/intermezzo/io_daemon.s', needed
by `fs/intermezzo/io_daemon.o'. Stop.
make[1]: *** [fs/intermezzo] Error 2
make: *** [fs] Error 2
please help
>>>At your finger tips ;-). Turn on CONFIG_INPUT via "Input device support"
>>>off the main page.
>>
>>I did not know what is that mean (off the man page)?
>>
>>Is that at menuconfig
>>or
>>should modify any source code?
>>
>
> Yes it is at off the first page of "make menuconfig".
>
--
Sincere Eric
www.linuxspice.com
linux pc for sale
^ permalink raw reply
* Re: [PATCH] S4bios for 2.5.52.
From: Pavel Machek @ 2002-12-17 23:18 UTC (permalink / raw)
To: Grover, Andrew; +Cc: ACPI mailing list
In-Reply-To: <EDC461A30AC4D511ADE10002A5072CAD04C7A5B6-OU+JdkIUtvd9zuciVAfUoVDQ4js95KgL@public.gmane.org>
Hi!
> > > I still am not clear on why we would want s4bios in 2.5.x,
> > since we have S4.
> > > Like you said, S4bios is easier to implement, but since
> > Pavel has done much
> > > of the heavy lifting required for S4 proper, I don't see the need.
> >
> > Let me counter this, I have to admit that I didn't try the
> > patch yet, but
> > my laptop does S4 BIOS, and I'd definitely prefer that to
> > swsusp, since
> > it's much faster and also I somewhat have more faith into S4 BIOS than
> > swsusp (as in: after resuming, it'll most likely either work
> > or crash, but
> > not cause any weird kinds of corruption). Since it does not
> > need not much
> > more to support it than S3, I don't see why you wouldn't want to give
> > users the option?
>
> Ok that's reasonable.
>
> My belief is that S4bios is a stopgap measure until S4 gets better. That
> said, I think you are right - it should go in for now, and then at some
> point in the future someone will say, "S4bios?? who needs *that* anymore??"
> and it will get pulled out. ;-)
Thanx. I'm looking forward to see it merged.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* [PATCH] Miscellaneous UML bug fixes
From: Jeff Dike @ 2002-12-17 23:23 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel
Please pull
http://jdike.stearns.org:5000/fixes-2.5
This update fixes a number of small bugs:
strtoul calls are checked such that an empty string doesn't look like
zero
fixed some ubd driver error checking
a host helper is searched for if it's not in its usual location
fixed a check for an irq being disabled
Jeff
arch/um/drivers/fd.c | 2 +-
arch/um/drivers/mcast_kern.c | 4 ++--
arch/um/drivers/port_user.c | 2 +-
arch/um/drivers/ubd_kern.c | 9 ++++++---
arch/um/drivers/xterm.c | 3 +++
arch/um/kernel/exitcode.c | 2 +-
arch/um/kernel/helper.c | 5 ++++-
arch/um/kernel/irq_user.c | 3 ++-
arch/um/kernel/tty_log.c | 2 +-
arch/um/os-Linux/file.c | 3 ++-
include/asm-um/system-generic.h | 1 +
11 files changed, 24 insertions(+), 12 deletions(-)
ChangeSet@1.797.78.1, 2002-11-18 21:53:20-05:00, jdike@uml.karaya.com
Merged a number of bug fixes from the 2.4 pool.
^ 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.