* [BK] [PATCH] ReiserFS assorted trivia
From: Hans Reiser @ 2002-12-14 21:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: reiserfs fixes for 2.5.51 --]
[-- Type: message/rfc822, Size: 11794 bytes --]
From: Oleg Drokin <green@namesys.com>
To: reiser@namesys.com
Subject: reiserfs fixes for 2.5.51
Date: Fri, 13 Dec 2002 20:04:24 +0300
Message-ID: <20021213200424.A8873@namesys.com>
Hello!
These five changesets contain fixes for reiserfs. They fix issue with
handling of displacing_large_files allocator option, a problem with
remounting from readwrite to readwrite mode if FS holds some deleted,
but not yet closed files, replace lock_kernel() stuff with reiserfs
analogs, some C99 designated initialisers fixes and fixes for annoying
warnings in fs/reiserfs/procfs.c if you compile with reiserfs statistics.
You can pull these from bk://thebsh.namesys.com/bk/reiser3-linux-2.5-fixes
ChangeSet@1.849, 2002-12-07 14:13:55+03:00, green@angband.namesys.com
reiserfs: Fixed annoying warnings in fs/reiserfs/procfs.c
ChangeSet@1.848, 2002-12-07 13:20:18+03:00, green@angband.namesys.com
reiserfs: C99 designated initializers, by Art Haas
ChangeSet@1.847, 2002-12-07 13:18:51+03:00, green@angband.namesys.com
reiserfs: lock_kernel is replaced with its reiserfs variant
ChangeSet@1.846, 2002-12-07 13:17:28+03:00, green@angband.namesys.com
reiserfs: Fix a problem with delayed unlinks and remounting RW filesystem RW.
ChangeSet@1.845, 2002-12-07 13:16:27+03:00, green@angband.namesys.com
reiserfs: Take into account file information even when not doing preallocation. Fixes a bug with displacing_large_files option.
Diffstats:
fs/reiserfs/dir.c | 6 +++---
fs/reiserfs/inode.c | 16 ++++++++--------
fs/reiserfs/journal.c | 5 ++---
fs/reiserfs/namei.c | 18 +++++++++---------
fs/reiserfs/procfs.c | 16 ++++++++--------
fs/reiserfs/super.c | 36 ++++++++++++++++++++----------------
include/linux/reiserfs_fs.h | 3 ++-
7 files changed, 52 insertions(+), 48 deletions(-)
Plain text patch:
# This is a BitKeeper generated patch for the following project:
# Project Name: Linux kernel tree
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet 1.844 -> 1.849
# fs/reiserfs/procfs.c 1.14 -> 1.15
# fs/reiserfs/inode.c 1.68 -> 1.70
# fs/reiserfs/super.c 1.54 -> 1.56
# fs/reiserfs/dir.c 1.17 -> 1.18
# fs/reiserfs/namei.c 1.44 -> 1.45
# fs/reiserfs/journal.c 1.59 -> 1.60
# include/linux/reiserfs_fs.h 1.45 -> 1.46
#
# The following is the BitKeeper ChangeSet Log
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.845
# reiserfs: Take into account file information even when not doing preallocation. Fixes a bug with displacing_large_files option.
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.846
# reiserfs: Fix a problem with delayed unlinks and remounting RW filesystem RW.
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.847
# reiserfs: lock_kernel is replaced with its reiserfs variant
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.848
# reiserfs: C99 designated initializers, by Art Haas
# --------------------------------------------
# 02/12/07 green@angband.namesys.com 1.849
# reiserfs: Fixed annoying warnings in fs/reiserfs/procfs.c
# --------------------------------------------
#
diff -Nru a/fs/reiserfs/dir.c b/fs/reiserfs/dir.c
--- a/fs/reiserfs/dir.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/dir.c Sat Dec 7 14:14:58 2002
@@ -18,9 +18,9 @@
int reiserfs_dir_fsync(struct file *filp, struct dentry *dentry, int datasync) ;
struct file_operations reiserfs_dir_operations = {
- read: generic_read_dir,
- readdir: reiserfs_readdir,
- fsync: reiserfs_dir_fsync,
+ .read = generic_read_dir,
+ .readdir = reiserfs_readdir,
+ .fsync = reiserfs_dir_fsync,
};
int reiserfs_dir_fsync(struct file *filp, struct dentry *dentry, int datasync) {
diff -Nru a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
--- a/fs/reiserfs/inode.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/inode.c Sat Dec 7 14:14:58 2002
@@ -490,7 +490,7 @@
return reiserfs_new_unf_blocknrs2(th, inode, allocated_block_nr, path, block);
}
#endif
- return reiserfs_new_unf_blocknrs (th, allocated_block_nr, path, block);
+ return reiserfs_new_unf_blocknrs (th, inode, allocated_block_nr, path, block);
}
int reiserfs_get_block (struct inode * inode, sector_t block,
@@ -2113,11 +2113,11 @@
}
struct address_space_operations reiserfs_address_space_operations = {
- writepage: reiserfs_writepage,
- readpage: reiserfs_readpage,
- releasepage: reiserfs_releasepage,
- sync_page: block_sync_page,
- prepare_write: reiserfs_prepare_write,
- commit_write: reiserfs_commit_write,
- bmap: reiserfs_aop_bmap
+ .writepage = reiserfs_writepage,
+ .readpage = reiserfs_readpage,
+ .releasepage = reiserfs_releasepage,
+ .sync_page = block_sync_page,
+ .prepare_write = reiserfs_prepare_write,
+ .commit_write = reiserfs_commit_write,
+ .bmap = reiserfs_aop_bmap
} ;
diff -Nru a/fs/reiserfs/journal.c b/fs/reiserfs/journal.c
--- a/fs/reiserfs/journal.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/journal.c Sat Dec 7 14:14:58 2002
@@ -1812,8 +1812,7 @@
struct reiserfs_journal_commit_task *ct = __ct;
struct reiserfs_journal_list *jl ;
- /* FIXMEL: is this needed? */
- lock_kernel();
+ reiserfs_write_lock(ct->p_s_sb);
jl = SB_JOURNAL_LIST(ct->p_s_sb) + ct->jindex ;
@@ -1824,7 +1823,7 @@
kupdate_one_transaction(ct->p_s_sb, jl) ;
}
reiserfs_kfree(ct->self, sizeof(struct reiserfs_journal_commit_task), ct->p_s_sb) ;
- unlock_kernel();
+ reiserfs_write_unlock(ct->p_s_sb);
}
static void setup_commit_task_arg(struct reiserfs_journal_commit_task *ct,
diff -Nru a/fs/reiserfs/namei.c b/fs/reiserfs/namei.c
--- a/fs/reiserfs/namei.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/namei.c Sat Dec 7 14:14:58 2002
@@ -1296,14 +1296,14 @@
*/
struct inode_operations reiserfs_dir_inode_operations = {
//&reiserfs_dir_operations, /* default_file_ops */
- create: reiserfs_create,
- lookup: reiserfs_lookup,
- link: reiserfs_link,
- unlink: reiserfs_unlink,
- symlink: reiserfs_symlink,
- mkdir: reiserfs_mkdir,
- rmdir: reiserfs_rmdir,
- mknod: reiserfs_mknod,
- rename: reiserfs_rename,
+ .create = reiserfs_create,
+ .lookup = reiserfs_lookup,
+ .link = reiserfs_link,
+ .unlink = reiserfs_unlink,
+ .symlink = reiserfs_symlink,
+ .mkdir = reiserfs_mkdir,
+ .rmdir = reiserfs_rmdir,
+ .mknod = reiserfs_mknod,
+ .rename = reiserfs_rename,
};
diff -Nru a/fs/reiserfs/procfs.c b/fs/reiserfs/procfs.c
--- a/fs/reiserfs/procfs.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/procfs.c Sat Dec 7 14:14:58 2002
@@ -78,7 +78,7 @@
struct super_block *sb;
char *format;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
if ( REISERFS_SB(sb)->s_properties & (1 << REISERFS_3_6) ) {
@@ -136,7 +136,7 @@
struct reiserfs_sb_info *r;
int len = 0;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
r = REISERFS_SB(sb);
@@ -229,7 +229,7 @@
int len = 0;
int level;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
r = REISERFS_SB(sb);
@@ -308,7 +308,7 @@
struct reiserfs_sb_info *r;
int len = 0;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
r = REISERFS_SB(sb);
@@ -352,7 +352,7 @@
int hash_code;
int len = 0;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
sb_info = REISERFS_SB(sb);
@@ -409,7 +409,7 @@
int len = 0;
int exact;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
sb_info = REISERFS_SB(sb);
@@ -461,7 +461,7 @@
struct journal_params *jp;
int len = 0;
- sb = procinfo_prologue((dev_t)data);
+ sb = procinfo_prologue((int)data);
if( sb == NULL )
return -ENOENT;
r = REISERFS_SB(sb);
@@ -604,7 +604,7 @@
{
return ( REISERFS_SB(sb)->procdir ) ? create_proc_read_entry
( name, 0, REISERFS_SB(sb)->procdir, func,
- ( void * ) sb->s_bdev->bd_dev) : NULL;
+ ( void * )(int) sb->s_bdev->bd_dev) : NULL;
}
void reiserfs_proc_unregister( struct super_block *sb, const char *name )
diff -Nru a/fs/reiserfs/super.c b/fs/reiserfs/super.c
--- a/fs/reiserfs/super.c Sat Dec 7 14:14:58 2002
+++ b/fs/reiserfs/super.c Sat Dec 7 14:14:58 2002
@@ -474,25 +474,25 @@
struct super_operations reiserfs_sops =
{
- alloc_inode: reiserfs_alloc_inode,
- destroy_inode: reiserfs_destroy_inode,
- write_inode: reiserfs_write_inode,
- dirty_inode: reiserfs_dirty_inode,
- delete_inode: reiserfs_delete_inode,
- put_super: reiserfs_put_super,
- write_super: reiserfs_write_super,
- write_super_lockfs: reiserfs_write_super_lockfs,
- unlockfs: reiserfs_unlockfs,
- statfs: reiserfs_statfs,
- remount_fs: reiserfs_remount,
+ .alloc_inode = reiserfs_alloc_inode,
+ .destroy_inode = reiserfs_destroy_inode,
+ .write_inode = reiserfs_write_inode,
+ .dirty_inode = reiserfs_dirty_inode,
+ .delete_inode = reiserfs_delete_inode,
+ .put_super = reiserfs_put_super,
+ .write_super = reiserfs_write_super,
+ .write_super_lockfs = reiserfs_write_super_lockfs,
+ .unlockfs = reiserfs_unlockfs,
+ .statfs = reiserfs_statfs,
+ .remount_fs = reiserfs_remount,
};
static struct export_operations reiserfs_export_ops = {
- encode_fh: reiserfs_encode_fh,
- decode_fh: reiserfs_decode_fh,
- get_parent: reiserfs_get_parent,
- get_dentry: reiserfs_get_dentry,
+ .encode_fh = reiserfs_encode_fh,
+ .decode_fh = reiserfs_decode_fh,
+ .get_parent = reiserfs_get_parent,
+ .get_dentry = reiserfs_get_dentry,
} ;
/* this struct is used in reiserfs_getopt () for containing the value for those
@@ -716,7 +716,7 @@
}
if (*mount_flags & MS_RDONLY) {
- /* remount rean-only */
+ /* remount read-only */
if (s->s_flags & MS_RDONLY)
/* it is read-only already */
return 0;
@@ -732,6 +732,10 @@
journal_mark_dirty(&th, s, SB_BUFFER_WITH_SB (s));
s->s_dirt = 0;
} else {
+ /* remount read-write */
+ if (!(s->s_flags & MS_RDONLY))
+ return 0; /* We are read-write already */
+
REISERFS_SB(s)->s_mount_state = sb_umount_state(rs) ;
s->s_flags &= ~MS_RDONLY ; /* now it is safe to call journal_begin */
journal_begin(&th, s, 10) ;
diff -Nru a/include/linux/reiserfs_fs.h b/include/linux/reiserfs_fs.h
--- a/include/linux/reiserfs_fs.h Sat Dec 7 14:14:58 2002
+++ b/include/linux/reiserfs_fs.h Sat Dec 7 14:14:58 2002
@@ -2073,13 +2073,14 @@
}
extern inline int reiserfs_new_unf_blocknrs (struct reiserfs_transaction_handle *th,
+ struct inode *inode,
b_blocknr_t *new_blocknrs,
struct path * path, long block)
{
reiserfs_blocknr_hint_t hint = {
.th = th,
.path = path,
- .inode = NULL,
+ .inode = inode,
.block = block,
.formatted_node = 0,
.preallocate = 0
^ permalink raw reply
* RE: kernel 2.4 smc1 problems ... advice please ...
From: James Don @ 2002-12-14 21:08 UTC (permalink / raw)
To: James Don, 'linuxppc-embedded@lists.linuxppc.org'
Fixed ... after I changed the immr to 0xff000000 from 0x02200000 I left a
for(;;); in start_kernel ... sorry for the uneccessary post ...
Jim
-----Original Message-----
From: James Don [mailto:JDon@spacebridge.com]
Sent: Saturday, December 14, 2002 2:37 PM
To: 'linuxppc-embedded@lists.linuxppc.org'
Subject: kernel 2.4 smc1 problems ... advice please ...
Hello,
I am cuurently trying to boot up the linux kernel using ppcboot 1.16 and the
2.4 kernel with only smc1 uart support as a start on an MPC860 FADS derived
board.
So far I have:
- ppcboot running great
- tftpboot graps my kernel puts in RAM
- bootm starts my kernel ... BUT no serial activity ...
I am using the vision ICE currently to debug the kernel start up but it has
a problem stepping through the 'rfi' etc when memory protection is running.
So currently I can only really peek at the PC and see that I am indeed
excuting kernel code.
I believe my memory map is ok:
MEM VIRT PHYS
RAM 0xc0000000 0x00000000
IMMR 0xff000000 0xff000000
My pc seems to get beyond start_kernel ... but I don't see the kernel banner
printed or anything ... with an ocillioscope I don't see any serial activity
at all after I exit ppcboot ...
I have check the following so far to the best of my abilities (until I get a
BDI 2000) ... and the MMU looks ok ... and my SMC port B settings are ok as
well.
Does anyone have any tips that could help me out? For some reason I think
either my MMU is not set to what I think it is ... or my SMC config has
tanked ...
Regards,
Jim
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [U-Boot-Users] PPC 405 _start code - Clarification
From: Wolfgang Denk @ 2002-12-14 20:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <EGEGIJHKDKJGAJMGIDPNCEHJCCAA.jwalden@digitalatlantic.com>
Dear Jerry,
in message <EGEGIJHKDKJGAJMGIDPNCEHJCCAA.jwalden@digitalatlantic.com> you wrote:
> Thanks for the clarification!
You are welcome.
> I am used to the x86 world, and when I disassemble something, I
> am used to seeing a one for one mapping from instruction to op-code.
This is the same with PowerPC. But there may be several equivalent
mnemonics to encode the same instruction. The green book ("The
Programming Environments") says: "To simplify assembly language
programming, a set of simplified mnemonics (referred to as extended
mnemonics in the architecture specification) and symbols is provided
..."
> It is obvious that I need to become more proficient in PPC assembly,
> how could you tell that the instruction we "equivalent" - did you
> use a tool, or is it that you are simply that familiar with the PPC
> assembly code.
In this case I didn't need a book; but you can actually look it up.
For example your first statement:
> addi r4,r0,0x0000
The green book lists for "addi":
addi rD,rA,SIMM
and the simplified mnemonics:
li rD,value equivalent to addi rD,0,value
la rD,disp(rA) equivalent to addi rD,rA,disp
subi rD,rA,value equivalent to addi rD,rA,-value
The listing you got from the disassembler:
> fff80100: 38 80 00 00 li r4,0
obviously matches rule 1 (well, it's only obvious if you now about
the special role or R0 in such cases :-).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Where people stand is not as important as which way they face.
- Terry Pratchett & Stephen Briggs, _The Discworld Companion_
^ permalink raw reply
* Re: Unresolved symbols in agpart
From: Stephen Torri @ 2002-12-14 20:54 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel
In-Reply-To: <20021214202636.GA4274@suse.de>
[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]
On Sat, 2002-12-14 at 14:26, Dave Jones wrote:
> On Sat, Dec 14, 2002 at 02:08:56PM -0600, Stephen Torri wrote:
> > I would like to help clear up the module problem in the linux kernel
> > (2.5.51). The problem I am getting is when I do "make install" there is
> > a report back that some symbols are unresolved. What I need to know is
> > how these symbols are supposed to be exported? I can grep the files to
> > find the symbols and correct this problem.
>
> Can you try with the patch at
> ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/2.5.51/
>
> and let me know if that fixes things ?
It does not appear to be doing so. The version of 2.5.51 that I have is
the bitkeeper version that I grab via bk.
Here is the output of "make install" for agpart.ko:
Kernel: arch/i386/boot/bzImage is ready
sh arch/i386/boot/install.sh 2.5.51 arch/i386/boot/bzImage System.map ""
depmod: *** Unresolved symbols in /lib/modules/2.5.51/kernel/agpgart.ko
depmod: __alloc_pages
depmod: remap_page_range
depmod: preempt_schedule
depmod: misc_deregister
depmod: pci_find_capability
depmod: unlock_page
depmod: inter_module_register
depmod: pci_bus_read_config_dword
depmod: kmalloc
depmod: __up_wakeup
depmod: __get_free_pages
depmod: vfree
depmod: global_flush_tlb
depmod: __page_cache_release
depmod: no_llseek
depmod: pm_unregister_all
depmod: __might_sleep
depmod: high_memory
depmod: panic
depmod: copy_to_user
depmod: ioremap_nocache
depmod: iounmap
depmod: change_page_attr
depmod: free_pages
depmod: smp_call_function
depmod: zone_table
depmod: pm_register
depmod: __PAGE_KERNEL
depmod: kfree
depmod: pci_devices
depmod: misc_register
depmod: vmalloc
depmod: contig_page_data
depmod: mem_map
depmod: copy_from_user
depmod: wake_up_process
depmod: printk
depmod: inter_module_unregister
depmod: pci_bus_write_config_dword
depmod: __down_failed
I grepped for "remap_page_range" found
System.map:c0149bf0 T remap_page_range
System.map:c0413a40 R __ksymtab_remap_page_range
Binary file vmlinux matches
I found that in kernel/ksym.c at line 108 is the line that is suppose to
export the symbol:
EXPORT_SYMBOL(remap_page_range);
Stephen
--
Stephen Torri <storri@sbcglobal.net>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Kernel with acpi hangs on compaq presario 1700
From: Heiko Ettelbrueck @ 2002-12-14 20:46 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <200212142221.15212.hogenberg11-RSh1/+X/PmFmR6Xm/wNWPw@public.gmane.org>
Hi Jaap,
if you don't want to use ACPI because of its IRQ routing, you could
simply try adding "pci=noacpi" at the boot prompt (or into lilo.conf /
grub's menu.lst) for your acpi kernel and try once again. I have a
Compaq Evo N160 and had the same problem (hang during boot) before I
tried the above kernel option.
I also got the advice to disable "Local APIC" and "SMP Support" in the
kernel configuration, but this didn't help in my case. Perhaps it will
in your one?
Regards,
Heiko
Jaap Hogenberg wrote:
> Hi,
>
> I'm new to this list so forgive me if this is a FAQ:
>
> I'm tried kernel 2.4.20 with the acpi patches of 12052002 and 12122002
> as well as a 2.5.51 with and without patch (12132002) and when I include
> acpi support , the kernel will hang when probing the PCI bus.
>
> I have seen references about acpi on compaq laptops indicating that it needed
> some tweaking (dumping acpi tables to a file) but as these were
> very old postings to linux-kernel mailing list , and the answers there
> were quite inconclusive I thought I'd ask here.
>
> Is there some (recent :-) ) documentation on getting acpi working
> on this laptop ?
> Or is there anything else I should try in my kernel config ?
>
> Regards,
>
> Jaap
>
>
> -------------------------------------------------------
> 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/
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
-------------------------------------------------------
This sf.net email is sponsored by:
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: i4l dtmf errors
From: Wolfgang Fritz @ 2002-12-14 20:51 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200212121145.26108.roy@karlsbakk.net>
Roy Sigurd Karlsbakk wrote:
> hi
>
> it seems isdn4linux detects DTMF tones from normal speach. This is
> rather annoying when using i4l for voice with Asterisk.org. This is
> tested on all recent kernels
The DTMF detection is broken since kernel 2.0.x. I have a patch for a
2.2 kernel which may manually be applied 2.4 kernels with some manual
work. It fixes an overflow problem in the goertzel algorithm (which
does the basic tone detection) and changes the algorithm to detect the
DTMF pairs. If interested, I can try to recover that patch.
Wolfgang
>
> see thread "[MGCP] Asterisk/D-Link phones generates ugly DTMF
> tones!!!" at http://www.marko.net/asterisk/archives/ for more info.
>
> roy
^ permalink raw reply
* Re: PCMCIA: pre-compiled driver packages
From: dashielljt @ 2002-12-14 20:42 UTC (permalink / raw)
To: Chuck Gelm; +Cc: Linux Newbie
In-Reply-To: <3DFB9211.99110E9C@gelm.net>
kernel 2.2.19 is at least two years old. To the best of my knowledge it
did not and does not provide drivers for any of your pcmcia cards. I have
never heard any of them being tested for on boot up at any rate. I also
do not know if any of the more recent kernel releases offer these drivers
either. Probably your best bet would be to set up a freshmeat.net account
and subscribe to the newsletters and check them out. It's like windows
update for linux but far less intrusive.
Jude <dashielljt(at)gmpexpress-dot-net>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: Networking/Becker et al [was Re: pci-skeleton duplex check]
From: Robert Love @ 2002-12-14 20:47 UTC (permalink / raw)
To: hps; +Cc: linux-kernel
In-Reply-To: <atfblt$nh2$1@forge.intermeta.de>
On Sat, 2002-12-14 at 08:28, Henning P. Schmiedehausen wrote:
> e) put an alan-cox-like entity between him and the linux kernel developers
> which translates. Worked terrific for Andre Hedrick. :-)
Isn't that what Jeff is?
No one seems to have a problem working with him. Jeff is the
maintainer. An "Alan Cox" buffer works great when the maintainer is
loony but Jeff is the maintainer and not a wacko. He can work with
Donald just fine if Donald plays the game.
(And I shall add I hope he does, because Donald is a gifted hacker)
Robert Love
^ permalink raw reply
* ide-scsi in 2.5.51
From: Willem Riede @ 2002-12-14 20:22 UTC (permalink / raw)
To: linux-scsi
In my efforts to make osst work on 2.5.51 I've been pretty successful with
the SC-30 (scsi) and the FW-30 (ieee1394). But the ide-scsi is giving me
trouble with the DI-30 (Atapi). I get the same problem with another ide
connected tape drive and st, by the way, so I am taking a closer look at
ide-scsi. When I load the module I get:
Dec 14 14:50:55 fallguy kernel: Badness in kobject_register at lib/kobject.c:113
Dec 14 14:50:55 fallguy kernel: Call Trace:
Dec 14 14:50:55 fallguy kernel: [<c01c7c88>] kobject_register+0x58/0x70
Dec 14 14:50:55 fallguy kernel: [<c01db442>] bus_add_driver+0x82/0xd0
Dec 14 14:50:55 fallguy kernel: [<c022bd00>] ide_drive_remove+0x0/0x30
Dec 14 14:50:55 fallguy kernel: [<c022bdec>] ide_register_driver+0xbc/0xf0
Dec 14 14:50:55 fallguy kernel: [<c0133f6a>] sys_init_module+0x1ba/0x1d0
Dec 14 14:50:55 fallguy kernel: [<c010b643>] syscall_call+0x7/0xb
Dec 14 14:50:55 fallguy kernel:
Dec 14 14:50:55 fallguy kernel: scsi HBA driver idescsi didn't set max_sectors, please fix the template
<3>ERROR: SCSI host `ide-scsi' has no error handling
Dec 14 14:50:55 fallguy kernel: ERROR: This is not a safe way to run your SCSI host
Dec 14 14:50:55 fallguy kernel: ERROR: The error handling must be added to this driver
Dec 14 14:50:55 fallguy kernel: Call Trace:
Dec 14 14:50:55 fallguy kernel: [<c023687d>] scsi_register+0x2cd/0x2e0
Dec 14 14:50:55 fallguy kernel: [<c02368be>] scsi_register_host+0x2e/0xe0
Dec 14 14:50:55 fallguy kernel: [<c0133f6a>] sys_init_module+0x1ba/0x1d0
Dec 14 14:50:55 fallguy kernel: [<c010b643>] syscall_call+0x7/0xb
Dec 14 14:50:55 fallguy kernel:
Dec 14 14:50:55 fallguy kernel: scsi4 : SCSI host adapter emulation for IDE ATAPI devices
So it seems that ide-scsi hasn't kept up with the evolving 2.5 kernel.
If no-one else is working on this, I'm prepared to take a stab at it,
but to get me jump-started any advise / hint will be most welcome.
Thanks, Willem Riede.
^ permalink raw reply
* Re: DMA from SCSI controller to PCI frame buffer memory.
From: Jason Howard @ 2002-12-14 20:29 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1039837312.25121.115.camel@irongate.swansea.linux.org.uk>
> In theory you can mmap the frame buffer memory, then do O_DIRECT I/O
> into it. In practice it will buffer (I hope it still does). One of the
> problems is that there are huge lists of PCI->AGP DMA errata in
> chipsets.
I am not accessing the AGP bus as my frame buffer is located on the PCI
bus.
00:08.0 Multimedia video controller: Unknown device f1d0:efac
Subsystem: Unknown device f1d0:efac
Flags: bus master, stepping, medium devsel, latency 64, IRQ 10
Memory at f4000000 (32-bit, non-prefetchable) [size=4K]
Memory at f6000000 (32-bit, prefetchable) [size=16M]
(I am working with the second memory address)
Any recommendations on where to start hacking? Would it be a good idea
to add O_DIRECT to a mmaped PCI space? The kernel should not be doing
any buffering whatsoever, as we will be coming close to filling the pci
bus up with transfers from direct disk->fb already. (We are already
doing buffering on the FB card as well)
Jason
--
Jason Howard
Professional:
SpectSoft, LLC
http://www.spectsoft.com jason@spectsoft.com
Phone: +1.209.847.7812 Fax: +1.209.847.7859
Personal:
http://www.psinux.org jason@psinux.org
Cell: +1.209.968.1289
Text Message: jasonsphone@psinux.org
^ permalink raw reply
* MCE 7 / Athlon / 2.4.20
From: Sapan Bhatia @ 2002-12-14 21:28 UTC (permalink / raw)
To: davej; +Cc: linux-kernel, reveillere
Hi,
I'm using a Compaq Evo N1005v: Athlon 1.5GHz/256MB RAM.
I get the following MCE when trying to boot 2.4.20, followed by a kernel
panic:
MCE 7
Bank: 3
Code: b40000000000083b
Addr: 00000001fc0003b3
I tried using your decoder (parsmec.c) but to no avail...
Regards,
Sapan
^ permalink raw reply
* Re: Unresolved symbols in agpart
From: Dave Jones @ 2002-12-14 20:26 UTC (permalink / raw)
To: Stephen Torri; +Cc: Linux Kernel
In-Reply-To: <1039896536.963.7.camel@base.torri.linux>
On Sat, Dec 14, 2002 at 02:08:56PM -0600, Stephen Torri wrote:
> I would like to help clear up the module problem in the linux kernel
> (2.5.51). The problem I am getting is when I do "make install" there is
> a report back that some symbols are unresolved. What I need to know is
> how these symbols are supposed to be exported? I can grep the files to
> find the symbols and correct this problem.
Can you try with the patch at
ftp://ftp.kernel.org/pub/linux/kernel/people/davej/patches/2.5/2.5.51/
and let me know if that fixes things ?
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* PCMCIA: pre-compiled driver packages
From: Chuck Gelm @ 2002-12-14 20:18 UTC (permalink / raw)
To: Linux Newbie
I have been trying to get several PCMCIA cards to work in my laptop.
(pentium 166MHz, 16 M RAM, 15 G HD). I am using Slakware v8.0.
(kernel 2.2.19)
#:ifconfig -a
Is not showing anything other than lo & dummy.
I have the following cards:
Netgear MA401 & FA411 (802.11b wireless & 10/100 network)
Belkin F5D6020 & F5D5020 (802.11b wireless & 10/100 network).
I am baffled as to whether I need the pcmcia-cs package.
I found this paragraph
(http://pcmcia-cs.sourceforge.net/ftp/doc/PCMCIA-HOWTO-2.html#ss2.1):
"Before starting, you should think about whether you really need to
compile the PCMCIA package yourself. All common Linux
distributions come with pre-compiled driver packages. Generally, you
only need to install the drivers from scratch if you need a
new feature of the current drivers, or if you've updated and/or
reconfigured your kernel in a way that is incompatible with the
drivers included with your Linux distribution. While compiling the
package is not technically difficult, it does require some
general Linux familiarity."
How do I tell if I have these packages?
If yes, How do I configure my system to use them?
Do I simply need to insmod/modprobe existing modules?
If yes, which modules go with which card?
Regards, Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* Re: [BK][PATCH] ReiserFS CPU and memory bandwidth efficient large writes
From: Oleg Drokin @ 2002-12-14 20:25 UTC (permalink / raw)
To: Andrew Morton; +Cc: Hans Reiser, Linux Kernel Mailing List
In-Reply-To: <3DFB904F.2ADDE2D4@digeo.com>
Hello!
On Sat, Dec 14, 2002 at 12:10:55PM -0800, Andrew Morton wrote:
> > Well, 450 bytes is way below 4k (~7 times less if we'd take task struct
> > into account) ;)
> > I can replace that on-stack array with kmalloc, but that probably
> > would be a lot of overhead for no benefit.
> It would be a little overhead. kmalloc is damn quick, and remember
> that this data has to be copied from userspace and has go to disk
> sometime. These things will make the kmalloc overhead very small.
Hm. Ok, this can be done.
> > What do you think is safe stack usage limit for a function?
> As little as possible?
reiserfs v3 was traditionally hungry on stack space I think.
> One way of measuring these things is with your trusty linusometer.
> Manfred and I were sent back to the drawing board last week for a
> function which used 400 bytes...
;)
> > (and btw you have not even seen reiser4 stack usage ;) )
> uh-oh. We need to be very sparing indeed.
> I had a patch once which would print out "maximum stack space
> ever used by this process" on exit, but Alan fumbled it. I shall
> resurrect it.
We have that for reiser4, that how we learn about all the stack overflows we
have/had ;)
Bye,
Oleg
^ permalink raw reply
* tasklet_kill: bug or feature?
From: Juergen Quade @ 2002-12-14 20:16 UTC (permalink / raw)
To: linux-kernel; +Cc: quade
Hi,
I had a closer look to the tasklet implementation, especially
to tasklet_kill. I do not understand, why at the end of
the function the TASKLET_STATE_SCHED bit is cleared. Is it
a bug or a feature? Maybe someone can help me.
The function tasklet_schedule does two things:
1. it sets the schedule_bit (TASKLET_STATE_SCHED)
2. if the bit wasn't set (cleared) it puts the tasklet on the
tasklet_vec list.
By the trick, to set the schedule_bit without putting
the tasklet on the list, a tasklet can be "killed"
(it is not on the list and tasklet_schedule is not going
to put it on the list). But in the current implementation
of tasklet_kill the schedule_bit is cleared (last line of
the function)? In this case the next tasklet_schedule
"works" and the tasklet-function will be called again.
So, is it a bug? What do we achieve by clearing the
schedule_bit? Can we remove the "clear_bit" line
(it is not necessary to call "set_bit", because
"test_and_set_bit" has set it before)?
Or what is _exactly_ the purpose of tasklet_kill?
Juergen.
=====================
void tasklet_kill(struct tasklet_struct *t)
{
if (in_interrupt())
printk("Attempt to kill tasklet from interrupt\n");
while (test_and_set_bit(TASKLET_STATE_SCHED, &t->state)) {
do
yield();
while (test_bit(TASKLET_STATE_SCHED, &t->state));
}
tasklet_unlock_wait(t);
clear_bit(TASKLET_STATE_SCHED, &t->state);
}
^ permalink raw reply
* [PATCH] Obvious(ish): 3c515 should work if ISAPNP is a module.
From: Matthew Bell @ 2002-12-14 20:12 UTC (permalink / raw)
To: linux-parport, linux-kernel
This is valid for at least 2.4.20 and earlier; it works for me, and I can't see any exceptional reason why it shouldn't work when ISAPNP is a module.
--- linux-2.4.19.orig/drivers/net/3c515.c 2002-02-25 19:37:59.000000000 +0000
+++ linux-2.4.19/drivers/net/3c515.c 2002-08-03 18:24:05.000000000 +0100
@@ -370,7 +370,7 @@
{ "Default", 0, 0xFF, XCVR_10baseT, 10000},
};
-#ifdef CONFIG_ISAPNP
+#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
static struct isapnp_device_id corkscrew_isapnp_adapters[] = {
{ ISAPNP_ANY_ID, ISAPNP_ANY_ID,
ISAPNP_VENDOR('T', 'C', 'M'), ISAPNP_FUNCTION(0x5051),
@@ -462,12 +462,12 @@
{
int cards_found = 0;
static int ioaddr;
-#ifdef CONFIG_ISAPNP
+#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
short i;
static int pnp_cards;
#endif
-#ifdef CONFIG_ISAPNP
+#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
if(nopnp == 1)
goto no_pnp;
for(i=0; corkscrew_isapnp_adapters[i].vendor != 0; i++) {
@@ -530,7 +530,7 @@
/* Check all locations on the ISA bus -- evil! */
for (ioaddr = 0x100; ioaddr < 0x400; ioaddr += 0x20) {
int irq;
-#ifdef CONFIG_ISAPNP
+#if defined(CONFIG_ISAPNP) || defined (CONFIG_ISAPNP_MODULE)
/* Make sure this was not already picked up by isapnp */
if(ioaddr == corkscrew_isapnp_phys_addr[0]) continue;
if(ioaddr == corkscrew_isapnp_phys_addr[1]) continue;
--
_______________________________________________
Get your free email from http://mymail.operamail.com
Powered by Outblaze
^ permalink raw reply
* Re: [BK][PATCH] ReiserFS CPU and memory bandwidth efficient large writes
From: Andrew Morton @ 2002-12-14 20:10 UTC (permalink / raw)
To: Oleg Drokin; +Cc: Hans Reiser, Linux Kernel Mailing List
In-Reply-To: <20021214222053.A10506@namesys.com>
Oleg Drokin wrote:
>
> Hello!
>
> On Sat, Dec 14, 2002 at 10:42:38AM -0800, Andrew Morton wrote:
> > > Find below the patch that address all the issues you've brought.
> > > It is on top of previous one.
> > > Do you think it is ok now?
> > I addresses the things I noticed and raised, thanks. Except for the
> > stack-space use. People are waving around 4k-stack patches, and we
> > do need to be careful there.
>
> Well, 450 bytes is way below 4k (~7 times less if we'd take task struct
> into account) ;)
> I can replace that on-stack array with kmalloc, but that probably
> would be a lot of overhead for no benefit.
It would be a little overhead. kmalloc is damn quick, and remember
that this data has to be copied from userspace and has go to disk
sometime. These things will make the kmalloc overhead very small.
> What do you think is safe stack usage limit for a function?
As little as possible?
One way of measuring these things is with your trusty linusometer.
Manfred and I were sent back to the drawing board last week for a
function which used 400 bytes...
> (and btw you have not even seen reiser4 stack usage ;) )
uh-oh. We need to be very sparing indeed.
I had a patch once which would print out "maximum stack space
ever used by this process" on exit, but Alan fumbled it. I shall
resurrect it.
^ permalink raw reply
* Unresolved symbols in agpart
From: Stephen Torri @ 2002-12-14 20:08 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
I would like to help clear up the module problem in the linux kernel
(2.5.51). The problem I am getting is when I do "make install" there is
a report back that some symbols are unresolved. What I need to know is
how these symbols are supposed to be exported? I can grep the files to
find the symbols and correct this problem.
Stephen
--
Stephen Torri <storri@sbcglobal.net>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Mirrored and shiftet fonts and logos
From: André Stierenberg @ 2002-12-14 19:53 UTC (permalink / raw)
To: linux-fbdev-devel
Hello,
i´m using the framebuffer driver pxafb for my board using the pxa processor
(Accelent IDP). I have a 4 bit monocrom display. when I run the framebuffer
I have some problems. The text in the console it in some way shifted. The
two parts of the font are switched. The first 4 pixels are at dest+2 and the
last 4 pixels at dest+0. And both parts are mirrored. Now I have done the
following in fbcon_cfb4.c in function fbcon_cfb4_putcs:
for (rows = fontheight(p), dest = dest0; rows-- ; dest += bytes) {
fb_writew((nibbletab_cfb4[rv(*cdat) >> 4] & eorx) ^ bgx, dest+2);
fb_writew((nibbletab_cfb4[rv(*cdat++) & 0xf] & eorx) ^ bgx, dest+0);
}
The function rv will reverse the bit order (bit 1 is bit 8, bit 2 is bit 7..
etc.).
And i have swaped the destination offset.
Now the characters are printed correctly. And in the linux logo, the
pinguin, something is also wrong. It seems the some pixels are mirrored too
whereas other pixels are correct.
What could this be and in what way can i fix the problem?
Andre
-------------------------------------------------------
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
* [linux-lvm] help: can't read name(s) of physical volumes (Debian kernel weirdness also involved)
From: Daniel J Hannum @ 2002-12-14 19:53 UTC (permalink / raw)
To: linux-lvm
Hi. I feel dumb for subscribing to the list just so I can yell out my
problem and hopefully someone can help, but I'm at the end of my rope
here.
Here's the situation. I just installed Debian 3.0 testing and I set it up
so that I was using their lvm10 package (version 1.0.4-6) for /usr, /var
/home, etc. (NOT /) It works fine off the kernel that Debian uses in its
install (2.4.18-bf2.4). BUT, if I install a stock Debian kernel with
apt-get (kernel-image-2.4.18-k7), lvm cannot see my physical volumes at
boot-time.
vgscan works fine, it detects my volume group 'main'
but vgchange does this:
vgchange -- ERROR: can't get name(s) of physical volumes
vgchange -- please check, if /proc is mounted
Now, since it works with one kernel but not with the other, well, it must
that there's something wrong with the stock Debian kernel. Except that
this same kernel booted this volume group multiple times before. So the
problem is something aside from the kernel itself.
There is a message that Debian's lvm10 package gives you when you install
it. Apparently, IF you have devfs in the kernel (and the broken kernel
does) then devfs must be mounted (which I think it is... /dev/.devfs
exists) OR devfsd must be installed (which I also did, to be safe). If you
don't do this, the stock kernels won't read the lvm physical volumes.
Sounds familiar, no? But I think I did what the package script told me to
do, and it still can't find them.
Now, I'm no newbie, and so if I only knew what that error message meant,
maybe I could fix it. The /dev/main/* devices exist, but I can't mount
them. /proc/lvm exists, but /proc/lvm/VGs doesn't contain my VG's. What
would cause lvm to see my volume group and set up the devices right
(according to the names of the lv's), but not be able to find the physical
volumes.
I know this came up before on the list (like 18 months ago), but the
thread wasn't helpful.
I would be grateful for any assistance. I can post diagnostic info, if you
tell me what to type :)
thanks
dan
^ permalink raw reply
* [U-Boot-Users] PPC 405 _start code
From: Jerry Walden @ 2002-12-14 19:49 UTC (permalink / raw)
To: u-boot
Greetings:
I just build a version of u-boot for the PPC 405GP.
If I disassemble the code that is generated I see the following:
fff80100 <_start>:
fff80100: 38 80 00 00 li r4,0
fff80104: 7c 99 eb a6 mtsgr r4
fff80108: 7c 9a eb a6 mtdcwr r4
fff8010c: 7c 94 f3 a6 mtesr r4
fff80110: 7c 9a f3 a6 mttcr r4
fff80114: 7c 81 03 a6 mtxer r4
fff80118: 7c 96 f3 a6 mtevpr r4
fff8011c: 38 80 10 00 li r4,4096
So to develop a deeper understanding of how all the pieces fit together
I went to the start.S module under the cpu subdirecory. There I
see the _start vector - however the code I see in start.S does not
correspond to the code that I disassembled.
What am I missing?
Kindest Regards,
Jerry
^ permalink raw reply
* Re: [PATCH] kexec for 2.5.51....
From: Greg KH @ 2002-12-14 19:49 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: linux-kernel, Eric W.Biederman
In-Reply-To: <200212141215.49449.tomlins@cam.org>
On Sat, Dec 14, 2002 at 12:15:49PM -0500, Ed Tomlinson wrote:
> Eric W. Biederman wrote:
>
> > Linus,
> >
> > My apologies for not resending this earlier I've been terribly
> > busy with other things..
> >
> > No changes are included since the last time I sent this except
> > the diff now patches cleanly onto 2.5.51. If there is some problem
> > holler and I will see about fixing it.
> >
> > When I bypass the BIOS in booting clients my only current failure
> > report is on an IBM NUMAQ and that almost worked.
>
> I applied this to a 2.5.51 kernel with usb and fbcon updated via bk pulls.
> Then after rebooting into the new kernel I tried
>
> kexec -l /vmlinux.25 --append="console=tty0 console=ttyS0,38400 video=matrox:mem:32 idebus=33 profile=1"
> kexec -ed
>
> This rebooted but hangs at:
>
> drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.0
Could you enable CONFIG_USB_DEBUG to hopefully see more debugging
messages from the uhci driver during boot, so we could narrow this down?
thanks,
greg k-h
^ permalink raw reply
* Re: Symlink indirection
From: Stephen Wille Padnos @ 2002-12-14 19:50 UTC (permalink / raw)
To: Andrew Walrond; +Cc: linux-kernel
In-Reply-To: <3DFB3983.3090602@walrond.org>
Andrew Walrond wrote:
> [snip]
> cat d/x
> "a/x"
>
> cat d/y
> "b/y"
>
> cat d/z
> "c/z"
What would you expect to happen if you then did:
echo "d/w" > d/w
Which physical directory would you expect a new file to go into?
- Steve
^ permalink raw reply
* kernel 2.4 smc1 problems ... advice please ...
From: James Don @ 2002-12-14 19:37 UTC (permalink / raw)
To: 'linuxppc-embedded@lists.linuxppc.org'
Hello,
I am cuurently trying to boot up the linux kernel using ppcboot 1.16 and the
2.4 kernel with only smc1 uart support as a start on an MPC860 FADS derived
board.
So far I have:
- ppcboot running great
- tftpboot graps my kernel puts in RAM
- bootm starts my kernel ... BUT no serial activity ...
I am using the vision ICE currently to debug the kernel start up but it has
a problem stepping through the 'rfi' etc when memory protection is running.
So currently I can only really peek at the PC and see that I am indeed
excuting kernel code.
I believe my memory map is ok:
MEM VIRT PHYS
RAM 0xc0000000 0x00000000
IMMR 0xff000000 0xff000000
My pc seems to get beyond start_kernel ... but I don't see the kernel banner
printed or anything ... with an ocillioscope I don't see any serial activity
at all after I exit ppcboot ...
I have check the following so far to the best of my abilities (until I get a
BDI 2000) ... and the MMU looks ok ... and my SMC port B settings are ok as
well.
Does anyone have any tips that could help me out? For some reason I think
either my MMU is not set to what I think it is ... or my SMC config has
tanked ...
Regards,
Jim
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* [U-Boot-Users] PPC 405 _start code - Clarification
From: Wolfgang Denk @ 2002-12-14 19:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <EGEGIJHKDKJGAJMGIDPNOEHHCCAA.jwalden@digitalatlantic.com>
In message <EGEGIJHKDKJGAJMGIDPNOEHHCCAA.jwalden@digitalatlantic.com> you wrote:
>
> what I expect to see it what I see in /cpu/start.S which looks like:
>
> .text
> .long 0x27051956 /* U-Boot Magic Number */
> .globl version_string
> version_string:
> .ascii U_BOOT_VERSION
> .ascii " (", __DATE__, " - ", __TIME__, ")"
> .ascii CONFIG_IDENT_STRING, "\0"
Let's ignore this part for now - you should find it at offset 0x0000.
_start is at offset 0x0100:
> _start:
...
> addi r4,r0,0x0000
> mtspr sgr,r4
> mtspr dcwr,r4
>
>
> Instead I see:
>
> fff80100 <_start>:
> fff80100: 38 80 00 00 li r4,0
> fff80104: 7c 99 eb a6 mtsgr r4
> fff80108: 7c 9a eb a6 mtdcwr r4
> fff8010c: 7c 94 f3 a6 mtesr r4
> fff80110: 7c 9a f3 a6 mttcr r4
> fff80114: 7c 81 03 a6 mtxer r4
> fff80118: 7c 96 f3 a6 mtevpr r4
> fff8011c: 38 80 10 00 li r4,4096
>
> So hence I am confused....
You confuse me. Why are you confused?
"addi r4,r0,0x0000" == "li r4,0"
"mtspr sgr,r4" == "mtsgr r4"
"mtspr dcwr,r4" == "mtdcwr r4"
...
Looks identical to me.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
You don't have to stay up nights to succeed; you have to stay awake
days.
^ 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.