Re: HELP!!!!!!!!

Re: HELP!!!!!!!!

[Stas Sergeev]

Hello.

Dinu M.C wrote:
> Phar Lap err 35: The 386 chip is currently executing
> in virtual 8086 mode under the control of another program.  You must 
> turn off this other program in order to use 386|DOS-Extender to run in
> protected mode."
Most often that means that you have a
DPMI disabled in your dosemu.conf.
Most often that means that you are
using an outdated version of dosemu.

Help!

[Raj Vishwanathan]

Can someone help? or point to some resources for me to move forward?

Raj

I am trying the following
------------------ Previous email --------------------------------
I am trying to setup and take a look at an system with CXL enabled

1. I downloaded and installed linux.5.11 + CXL patches on a regular qemu system
2. I built qemu using Ben Widawsky's CXL-2.0 branch ( I see that there
is a 2.0v4 tree)
3. I also built ndactl  from 2.0v2 branch

From what I understand, I use the ndactl to create a  memory namespace
and I use this in the qemu command line to start. Given this and the
Linux having CXL support  I should be able to see the CXL.mem device
with lspci. Correct me if I am completely messed up.

I am not able to create the memory namespace with ndctl

I tried with

"./ndctl  create-namespace -t pmem -m raw -n mem0 -v -s 268435456" and
it fails with

"failed to create namespace: No such device or address"

Is there a step by step direction of how to test CXL on Linux? I can
document this process if someone can describe where am I making a
mistake

HELP!

[Dhanush K.S]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

Hello,

I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to Yocto
2.5.

After cloning the Poky repository, I was confused with which tag to
checkout with.

Could you please help me understand the difference between the tags
*"sumo-19.0.0"
*and *"yocto-2.5"*

As far as I understand, both mean the same since "2.5" is the
DISTRO_VERSION and "sumo" is the DISTRO_CODENAME.

But is still the same with the checkout tags as well?

Many thanks in advance!

Mit freundlichen Grüßen / Best Regards,
Dhanush Keshava Reddy Soppahalli
Mob: +4915216144064

[-- Attachment #2: Type: text/html, Size: 1954 bytes --]

Re: HELP!

[Alexander Kanavin]

You don't need to check out a specific tag. Just switch to the latest
commit in the branch you want (e.g. sumo).

Alex

2018-08-09 14:39 GMT+02:00 Dhanush K.S <dhanush.ks@gmail.com>:
> Hello,
>
> I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to Yocto
> 2.5.
>
> After cloning the Poky repository, I was confused with which tag to checkout
> with.
>
> Could you please help me understand the difference between the tags
> "sumo-19.0.0" and "yocto-2.5"
>
> As far as I understand, both mean the same since "2.5" is the DISTRO_VERSION
> and "sumo" is the DISTRO_CODENAME.
>
> But is still the same with the checkout tags as well?
>
> Many thanks in advance!
>
> Mit freundlichen Grüßen / Best Regards,
> Dhanush Keshava Reddy Soppahalli
> Mob: +4915216144064
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: HELP!

[Bas Mevissen]

On 2018-08-09 14:39, Dhanush K.S wrote:
> Hello,
> 
> I am currently trying to migrate from Yocto 1.8 Poky Fido 13.0.0 to
> Yocto 2.5.
> 
> After cloning the Poky repository, I was confused with which tag to
> checkout with.
> 

With a fresh release like Sumo, it is better to stay at the HEAD of the 
sumo branch for some time. Updates here should not break things, but fix 
bugs instead.
When it stabilizes or when you are making a release, you can use a 
certain commit or release tag.

> Could you please help me understand the difference between the tags
> "SUMO-19.0.0" and "YOCTO-2.5"
> 

Both tags point to the same commit (da3625c52e), so choose one.

> As far as I understand, both mean the same since "2.5" is the
> DISTRO_VERSION and "sumo" is the DISTRO_CODENAME.
> 
> But is still the same with the checkout tags as well?
> 
> Many thanks in advance!
> 
> Mit freundlichen Grüßen / Best Regards,
> Dhanush Keshava Reddy Soppahalli
> Mob: +4915216144064

-- Bas

Help!

[Raymond Jender]

Since I appear to be reaching the list, here goes.

I am running Ubuntu 12.04.  I have a Sabrent USB 2.0 grabber with a
Sony HDR SR11 plugged into it.
I am using the most current stk1160 driver.

I can see video using Camorama as well as a couple other tools.

Skype does not see my video.  Yahoo Messenger does see my video.
WebRTC does not access my camera.

Any ideas how I can trouble shoot this?

Thanks,

Ray

Help?

[David Thomas]

I can get bitbake to run as root but I don't let it continue as it is
not advised.

As user I get this:

Traceback (most recent call last):
  File "/home/dthomas/bitbake/bin/bitbake", line 234, in <module>
    ret = main()
  File "/home/dthomas/bitbake/bin/bitbake", line 197, in main
    server = ProcessServer(server_channel, event_queue, configuration)
  File "/home/dthomas/bitbake/lib/bb/server/process.py", line 78, in __init__
    self.cooker = BBCooker(configuration, self.register_idle_function)
  File "/home/dthomas/bitbake/lib/bb/cooker.py", line 77, in __init__
    self.parseConfigurationFiles(self.configuration.file)
  File "/home/dthomas/bitbake/lib/bb/cooker.py", line 529, in
parseConfigurationFiles
    bb.event.fire(bb.event.ConfigParsed(), self.configuration.data)
IOError: [Errno 1] Operation not permitted


I have tried everything. I am using Fedora 13 and have followed every
guide to the letter. It seems to be a permissions issue but where, I
have almost given up trying. As always, there is no info on the this
anywhere that is remotely useful

Any help is appreciated?

-- 
Dave Thomas
MicroBee Systems, Inc
1429 Weatherly Road, Suite G
Huntsville, AL 35803-1187
256-489-6671 (Voice)
256-426-2431 (Mobile)
256-489-6673 (FAX)
www.microbee-systems.com
"Innovative Solutions for an Embedded World"

This message is intended for the sole use of the addressee, and may
contain information that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the addressee you are
hereby notified that you may not use, copy, disclose, or distribute to
anyone the message or any information contained in the message. If you
have received this message in error, please immediately advise the
sender by reply email and delete this message.

-- 
Dave Thomas
MicroBee Systems, Inc
1429 Weatherly Road, Suite G
Huntsville, AL 35803-1187
256-489-6671 (Voice)
256-426-2431 (Mobile)
256-489-6673 (FAX)
www.microbee-systems.com
"Innovative Solutions for an Embedded World"

This message is intended for the sole use of the addressee, and may
contain information that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the addressee you are
hereby notified that you may not use, copy, disclose, or distribute to
anyone the message or any information contained in the message. If you
have received this message in error, please immediately advise the
sender by reply email and delete this message.

Re: Help?

[Henning Heinold]

On Sat, Oct 29, 2011 at 04:50:58PM -0500, David Thomas wrote:
> I can get bitbake to run as root but I don't let it continue as it is
> not advised.
> 
> As user I get this:
> 
> Traceback (most recent call last):
>   File "/home/dthomas/bitbake/bin/bitbake", line 234, in <module>
>     ret = main()
>   File "/home/dthomas/bitbake/bin/bitbake", line 197, in main
>     server = ProcessServer(server_channel, event_queue, configuration)
>   File "/home/dthomas/bitbake/lib/bb/server/process.py", line 78, in __init__
>     self.cooker = BBCooker(configuration, self.register_idle_function)
>   File "/home/dthomas/bitbake/lib/bb/cooker.py", line 77, in __init__
>     self.parseConfigurationFiles(self.configuration.file)
>   File "/home/dthomas/bitbake/lib/bb/cooker.py", line 529, in
> parseConfigurationFiles
>     bb.event.fire(bb.event.ConfigParsed(), self.configuration.data)
> IOError: [Errno 1] Operation not permitted
> 
> 
> I have tried everything. I am using Fedora 13 and have followed every

Why don't use some more up to date distribution?

> guide to the letter. It seems to be a permissions issue but where, I
> have almost given up trying. As always, there is no info on the this
> anywhere that is remotely useful
> 

Use "ls -la" and "find" to find out permissions and ownership. Hence you used
root user in the first place its likely there has something the wrong permisions.

If nothing helps start from the beginning, that is most of time easier and faster.

> Any help is appreciated?
Sure.

Bye Henning

Re: Help?

[David Thomas]

I used Fedora 13 after trying to use 15. I ran into all sorts of issues with 15 and the last issue I encountered was gmake 3.82 and patch versions. 

After working that angle for a while I downgraded to 13 as it had all the correct versions of gmake, etc. I did not install as root any package unless it was the only way to get it to install using sudo.

I ran it as root as a experiment after messing with trying to resolve this permissions issue for several days. 
It is not a permissions issue in my OE directory, there is access taking place somewhere else in the file system it does not like but I cannot seem to resolve where this access attempt is taking place.

I went back in and reinstalled everything related to OE, same result. Time to toss in the towel and rebuild linux again?




On Oct 30, 2011, at 5:30 AM, Henning Heinold wrote:

> On Sat, Oct 29, 2011 at 04:50:58PM -0500, David Thomas wrote:
>> I can get bitbake to run as root but I don't let it continue as it is
>> not advised.
>> 
>> As user I get this:
>> 
>> Traceback (most recent call last):
>>  File "/home/dthomas/bitbake/bin/bitbake", line 234, in <module>
>>    ret = main()
>>  File "/home/dthomas/bitbake/bin/bitbake", line 197, in main
>>    server = ProcessServer(server_channel, event_queue, configuration)
>>  File "/home/dthomas/bitbake/lib/bb/server/process.py", line 78, in __init__
>>    self.cooker = BBCooker(configuration, self.register_idle_function)
>>  File "/home/dthomas/bitbake/lib/bb/cooker.py", line 77, in __init__
>>    self.parseConfigurationFiles(self.configuration.file)
>>  File "/home/dthomas/bitbake/lib/bb/cooker.py", line 529, in
>> parseConfigurationFiles
>>    bb.event.fire(bb.event.ConfigParsed(), self.configuration.data)
>> IOError: [Errno 1] Operation not permitted
>> 
>> 
>> I have tried everything. I am using Fedora 13 and have followed every
> 
> Why don't use some more up to date distribution?
> 
>> guide to the letter. It seems to be a permissions issue but where, I
>> have almost given up trying. As always, there is no info on the this
>> anywhere that is remotely useful
>> 
> 
> Use "ls -la" and "find" to find out permissions and ownership. Hence you used
> root user in the first place its likely there has something the wrong permisions.
> 
> If nothing helps start from the beginning, that is most of time easier and faster.
> 
>> Any help is appreciated?
> Sure.
> 
> Bye Henning
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Help?

[Martin Panter]

>> On Sat, Oct 29, 2011 at 04:50:58PM -0500, David Thomas wrote:
>>>  File "/home/dthomas/bitbake/lib/bb/cooker.py", line 529, in
>>> parseConfigurationFiles
>>>    bb.event.fire(bb.event.ConfigParsed(), self.configuration.data)
>>> IOError: [Errno 1] Operation not permitted

“Operation not permitted” is EPERM, which is different from EACCESS
“Permission denied”. Normally you get the permission denied issue for
file permission issues, and “not permitted” for trying to do something
like killing a root process as a normal user.

Have you tried using strace on bitbake? See if you can find if there's
an actual system call returning EPERM just before Python raises the
IOError exception.

-Marty

Re: Help?

[David Thomas]

I had a feeling it was a process issue. It is happening on bb.fire.event and so I was thinking it has something to do with that event wanting to do something unallowed.




On Oct 30, 2011, at 7:53 AM, Martin Panter wrote:

>>> On Sat, Oct 29, 2011 at 04:50:58PM -0500, David Thomas wrote:
>>>> File "/home/dthomas/bitbake/lib/bb/cooker.py", line 529, in
>>>> parseConfigurationFiles
>>>>   bb.event.fire(bb.event.ConfigParsed(), self.configuration.data)
>>>> IOError: [Errno 1] Operation not permitted
> 
> “Operation not permitted” is EPERM, which is different from EACCESS
> “Permission denied”. Normally you get the permission denied issue for
> file permission issues, and “not permitted” for trying to do something
> like killing a root process as a normal user.
> 
> Have you tried using strace on bitbake? See if you can find if there's
> an actual system call returning EPERM just before Python raises the
> IOError exception.
> 
> -Marty
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: Help?

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1730 bytes --]

On Sun, Oct 30, 2011 at 08:00:28AM -0500, David Thomas wrote:
> I had a feeling it was a process issue. It is happening on bb.fire.event and so I was thinking it has something to do with that event wanting to do something unallowed.

I do not remember the exact error, but I would check the permissions on
/dev/shm or /run/shm (depends on your distribution).

Regards,

> 
> 
> 
> 
> On Oct 30, 2011, at 7:53 AM, Martin Panter wrote:
> 
> >>> On Sat, Oct 29, 2011 at 04:50:58PM -0500, David Thomas wrote:
> >>>> File "/home/dthomas/bitbake/lib/bb/cooker.py", line 529, in
> >>>> parseConfigurationFiles
> >>>>   bb.event.fire(bb.event.ConfigParsed(), self.configuration.data)
> >>>> IOError: [Errno 1] Operation not permitted
> > 
> > “Operation not permitted” is EPERM, which is different from EACCESS
> > “Permission denied”. Normally you get the permission denied issue for
> > file permission issues, and “not permitted” for trying to do something
> > like killing a root process as a normal user.
> > 
> > Have you tried using strace on bitbake? See if you can find if there's
> > an actual system call returning EPERM just before Python raises the
> > IOError exception.
> > 
> > -Marty
> > 
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Help!

[Jesús Bermúdez]

Hello all,

if you could help us, for we are completely desperated...

We have a raid5 with 3 disks that got out of sync due to a power failure. After tried to assemble (with mdadm --assemble --force /dev/md0) it says:

md: md0 stopped mdbind sdb2 bind sda2 bind sdc2

md: md0: array is not clean starting background reconstruction

raid 5  device sdc2 operational as raid disk 0
    device sda2 operational as raid disk 2
    device sdb2 operational as raid disk 1

allocated 32kb for md0

raid level 5 set md0 active with 3 out 3 devices algorithm 0

raid 5 conf printout

rd:3 wd:3

disk 0,0:1 /dev/sdc2
disk 1,0:1 /dev/sdb2
disk 2,0:1 /dev/sda2

md0: bitmap file is out of date 892893
forcing full recovery

md0: bitmap file is out of date doing full recovery

md0: bitmap initialisation failed: -5

md0: failed to create bitmap (-5)

md: pers->run() failed

mdadm: failed to run _array /dev/md0: input / output error

Tried to stop the array and reassemble it with:

mdadm --assemble --force --scan
mdadm --assemble --force --scan /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2
mdadm --assemble --force --run /dev/md0 /dev/sda2 /dev/sdb2
mdadm --assemble --force --run /dev/md0 /dev/sda2 /dev/sdc2
mdadm --assemble --force --run /dev/md0 /dev/sdb2 /dev/sdc2

Tried to solve the bitmap problem with:

mdadm --grow /dev/md0 --bitmap=none
mdadm --grow /dev/md0 --bitmap=internal
mdadm --grow /dev/md0 --bitmap=none --force
mdadm --grow /dev/md0 --bitmap=internal --force

Tried to fake the 'clean' status of the array with:

echo "clean" > /sys/block/md0/md/array_state

Tried to boot the array from grub with:

    md-mod.start_dirty_degraded=1

None of these commands have worked. Here are the details of the array and everyone of the disks:

-----------------------------------------------------------------------------------------------------------------------------------
mdadm -D /dev/md0

dev/md0
version: 01.00.03
creation time: august 28 18:58:39 2009
raid level: raid5
used dev size 83891328 (80:01 hid 85:90 gdb)
raid devices: 3
total drives: 3
preferred minor: 0
persistent: superblock is persistent
update time: tue oct 19 15:09 2010
Status: active, not started
Active devices: 3
Working devices: 3
Failed devices: 0
Spare device: 0
layout: left assimetric
chunk size: 128k
name: 0

UUID: ae9bd4fe:994ce882:4fa035e6:8094fc1a
events: 893

    Number   Major   Minor   RaidDevice State
    0    8    34    0    active sync /dev/sdc2
    1    8    18    1    active sync /dev/sdb2
    3    8    2    2    active sync /dev/sda2

-----------------------------------------------------------------------------------------------------------------------------------
mdadm --examine /dev/sd[abc]2


/dev/sda2:

Magic:a92b4efc
Version:1,0
Featura Map:0x1
Array UUID:ae9bd4fe:994ce882:4fa035e6:8094fc1a
Name:0
Creation Time:Fri Aug 28 18:58:39 2009
Raid Level:Raid5
Raid Devices:3:Avail Dev Size:167782712 (80,01GIB 85,90 GB)
Array Size:335565312 (160,01 GIB 171,81 GB)
Used Dev Size:167782656 (80,01 GIB 85,90GB)
Super Offset:167782840 Sectors
State:Active
Device UUID:bbc156a7:6f3af82d:94714923:e212967a
Internal Bitmap:-81 sectors from superblock
Update Time:re Oct 19 15:49:08 2010
Checksum:54a35562 - correct
Events:893
Layout:left-asymmetric
Chunk Size:128K
Array Slot:3 (0. 1, failed, 2)
Array State:uuU 1 failed



/dev/sdb2:
	

Magic:a92b4efc
Version:1,0
Feature Map:0x1
Array UUID:ae9bd4fe:994ce882:4fa035e6:8094fc1a
Name:0
Creation Time:Fri Aug 28 18:58:39 2009
Raid Level:raid5
Raid Devices:3
Avail Dev Size:167782712 (80,01 GIB 85,90 GB)
Array Size:335565312 (160,01 GIB 171,81 GB)
Used Dev Size:167782656 (80,01 GIB 85,90 GB)
Super Offset:167782840 sectors
State:Active
Device UUID:d067101e:19056fdd:6b6e58fc:92128788
Internal Bimap:-81 sectors from superblock
Update Time:Tue Oct 19 15:49:08 2010
Checksum:61d3c2bf
Events:893
Layout:left-asymmetric
Chunk Size:128k
Array Slot:1 (0,  1, failed, 2)
Array State:uUu 1 failed

/dev/sdc2:
	
Magic:a92b4efc
Version:1,0
Featura Map:0x1
Array UUID:ae9bd4fe:994ce882:4fa035e6:8094fc1a
Name:0
Creation Time:Fri Aug 28 18:58:39 2009
Raid Level:raid5
Raid Devices:3
Avail Dev Size:167782712 (80,01 GIB 85,90 GB)
Array Size:335565312 (160,01 GIB 171,81 GB)
Used Dev Size:167782656 (80,01 GIB 85,90 GB)
Super Offset:167782840 sectors
State:active
Device UUID:0a1c2c74:04b9187f:6ab6b5cb:894d8b38
Internal Bimap:-81 sectos from superblock
Update Time:Tue Oct 19 15:49:08 2010
Checksum:d8faadc0 - correct
Events:893
Layout:left-asymmetric
Chunk Size:128K
Array Slot:0 (0, 1, failed, 2)
Array State:Uuu 1 failed

-----------------------------------------------------------------------------------------------------------------------------------

mdadm --examine-bitmap /dev/sd[abc]2
	
Filename /dev/sda2

Magic 6d746962
Version 4
UUID ae9bd4fe:994ce882:4fa035e6:8094fc1a
Events 892
Events Cleared 892
State Out of date
Chunksize 256KB
Daemon 5s flush period
Write Mode Normal
Sync Size 83891328 (80,01 GIB 85,90 GB)
Bitmap 327701 BITS (CHUNKS), 325633 DIRTY (99,4%)

Filename /dev/sdb2

Magic 6d746962
Version 4
UUID ae9bd4fe:994ce882:4fa035e6:8094fc1a
Events 892
Events Cleared 892
State Out of date
Chunksize 256KB
Daemon 5s flush period
Write Mode Normal
Sync Size 83891328 (80,01 GIB 85,90 GB)
Bitmap 327701 BITS (CHUNKS), 325633 DIRTY (99,4%)

Filename /dev/sdc2
Magic 6d746962
Version 4
UUID ae9bd4fe:994ce882:4fa035e6:8094fc1a
events 892
Events Cleared 892

State Out of date
Chunksize 256 KB
Daemon 5s flush period
Write Mode Normal
Sync Size 83891328 (80,01 GIB 85,90 GB)
Bitmap 327701 BITS (CHUNKS), 325633 DIRTY (99,4%)

-----------------------------------------------------------------------------------------------------------------------------------

cat /sys/bplock/md0/md/array_state

inactive


cat /sys/block/md0/md/degraded

cat /sys/block/md0/md/degraded: No such file or directory


cat /sys/block/md0/md/dev-sda2/errors

0

cat /sys/block/md0/md/dev-sda2/state

in_sync


cat /sys/block/md0/md/dev-sdb2/errors

24


cat /sys/block/md0/md/dev-sdb2/state

in_sync


cat /sys/block/md0/md/dev-sdc2/errors

0


cat /sys/block/md0/md/dev-sdc2/state

in_sync
-----------------------------------------------------------------------------------------------------------------------------------

Thanks in advance.

-- 
Jesus Bermudez Riquelme 


Iten, S.L. 

Re: Help!

[Janek Kozicki]

what kernel version and mdadm version?




Jesús Bermúdez said:     (by the date of Fri, 22 Oct 2010 16:51:20 +0200 (CEST))

> Hello all,
> 
> if you could help us, for we are completely desperated...
> 
> We have a raid5 with 3 disks that got out of sync due to a power failure. After tried to assemble (with mdadm --assemble --force /dev/md0) it says:
> 
> md: md0 stopped mdbind sdb2 bind sda2 bind sdc2
> 
> md: md0: array is not clean starting background reconstruction
> 
> raid 5  device sdc2 operational as raid disk 0
>     device sda2 operational as raid disk 2
>     device sdb2 operational as raid disk 1
> 
> allocated 32kb for md0
> 
> raid level 5 set md0 active with 3 out 3 devices algorithm 0
> 
> raid 5 conf printout
> 
> rd:3 wd:3
> 
> disk 0,0:1 /dev/sdc2
> disk 1,0:1 /dev/sdb2
> disk 2,0:1 /dev/sda2
> 
> md0: bitmap file is out of date 892893
> forcing full recovery
> 
> md0: bitmap file is out of date doing full recovery
> 
> md0: bitmap initialisation failed: -5
> 
> md0: failed to create bitmap (-5)
> 
> md: pers->run() failed
> 
> mdadm: failed to run _array /dev/md0: input / output error
> 
> Tried to stop the array and reassemble it with:
> 
> mdadm --assemble --force --scan
> mdadm --assemble --force --scan /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2
> mdadm --assemble --force --run /dev/md0 /dev/sda2 /dev/sdb2
> mdadm --assemble --force --run /dev/md0 /dev/sda2 /dev/sdc2
> mdadm --assemble --force --run /dev/md0 /dev/sdb2 /dev/sdc2
> 
> Tried to solve the bitmap problem with:
> 
> mdadm --grow /dev/md0 --bitmap=none
> mdadm --grow /dev/md0 --bitmap=internal
> mdadm --grow /dev/md0 --bitmap=none --force
> mdadm --grow /dev/md0 --bitmap=internal --force
> 
> Tried to fake the 'clean' status of the array with:
> 
> echo "clean" > /sys/block/md0/md/array_state
> 
> Tried to boot the array from grub with:
> 
>     md-mod.start_dirty_degraded=1
> 
> None of these commands have worked. Here are the details of the array and everyone of the disks:
> 
> -----------------------------------------------------------------------------------------------------------------------------------
> mdadm -D /dev/md0
> 
> dev/md0
> version: 01.00.03
> creation time: august 28 18:58:39 2009
> raid level: raid5
> used dev size 83891328 (80:01 hid 85:90 gdb)
> raid devices: 3
> total drives: 3
> preferred minor: 0
> persistent: superblock is persistent
> update time: tue oct 19 15:09 2010
> Status: active, not started
> Active devices: 3
> Working devices: 3
> Failed devices: 0
> Spare device: 0
> layout: left assimetric
> chunk size: 128k
> name: 0
> 
> UUID: ae9bd4fe:994ce882:4fa035e6:8094fc1a
> events: 893
> 
>     Number   Major   Minor   RaidDevice State
>     0    8    34    0    active sync /dev/sdc2
>     1    8    18    1    active sync /dev/sdb2
>     3    8    2    2    active sync /dev/sda2
> 
> -----------------------------------------------------------------------------------------------------------------------------------
> mdadm --examine /dev/sd[abc]2
> 
> 
> /dev/sda2:
> 
> Magic:a92b4efc
> Version:1,0
> Featura Map:0x1
> Array UUID:ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Name:0
> Creation Time:Fri Aug 28 18:58:39 2009
> Raid Level:Raid5
> Raid Devices:3:Avail Dev Size:167782712 (80,01GIB 85,90 GB)
> Array Size:335565312 (160,01 GIB 171,81 GB)
> Used Dev Size:167782656 (80,01 GIB 85,90GB)
> Super Offset:167782840 Sectors
> State:Active
> Device UUID:bbc156a7:6f3af82d:94714923:e212967a
> Internal Bitmap:-81 sectors from superblock
> Update Time:re Oct 19 15:49:08 2010
> Checksum:54a35562 - correct
> Events:893
> Layout:left-asymmetric
> Chunk Size:128K
> Array Slot:3 (0. 1, failed, 2)
> Array State:uuU 1 failed
> 
> 
> 
> /dev/sdb2:
> 	
> 
> Magic:a92b4efc
> Version:1,0
> Feature Map:0x1
> Array UUID:ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Name:0
> Creation Time:Fri Aug 28 18:58:39 2009
> Raid Level:raid5
> Raid Devices:3
> Avail Dev Size:167782712 (80,01 GIB 85,90 GB)
> Array Size:335565312 (160,01 GIB 171,81 GB)
> Used Dev Size:167782656 (80,01 GIB 85,90 GB)
> Super Offset:167782840 sectors
> State:Active
> Device UUID:d067101e:19056fdd:6b6e58fc:92128788
> Internal Bimap:-81 sectors from superblock
> Update Time:Tue Oct 19 15:49:08 2010
> Checksum:61d3c2bf
> Events:893
> Layout:left-asymmetric
> Chunk Size:128k
> Array Slot:1 (0,  1, failed, 2)
> Array State:uUu 1 failed
> 
> /dev/sdc2:
> 	
> Magic:a92b4efc
> Version:1,0
> Featura Map:0x1
> Array UUID:ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Name:0
> Creation Time:Fri Aug 28 18:58:39 2009
> Raid Level:raid5
> Raid Devices:3
> Avail Dev Size:167782712 (80,01 GIB 85,90 GB)
> Array Size:335565312 (160,01 GIB 171,81 GB)
> Used Dev Size:167782656 (80,01 GIB 85,90 GB)
> Super Offset:167782840 sectors
> State:active
> Device UUID:0a1c2c74:04b9187f:6ab6b5cb:894d8b38
> Internal Bimap:-81 sectos from superblock
> Update Time:Tue Oct 19 15:49:08 2010
> Checksum:d8faadc0 - correct
> Events:893
> Layout:left-asymmetric
> Chunk Size:128K
> Array Slot:0 (0, 1, failed, 2)
> Array State:Uuu 1 failed
> 
> -----------------------------------------------------------------------------------------------------------------------------------
> 
> mdadm --examine-bitmap /dev/sd[abc]2
> 	
> Filename /dev/sda2
> 
> Magic 6d746962
> Version 4
> UUID ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Events 892
> Events Cleared 892
> State Out of date
> Chunksize 256KB
> Daemon 5s flush period
> Write Mode Normal
> Sync Size 83891328 (80,01 GIB 85,90 GB)
> Bitmap 327701 BITS (CHUNKS), 325633 DIRTY (99,4%)
> 
> Filename /dev/sdb2
> 
> Magic 6d746962
> Version 4
> UUID ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Events 892
> Events Cleared 892
> State Out of date
> Chunksize 256KB
> Daemon 5s flush period
> Write Mode Normal
> Sync Size 83891328 (80,01 GIB 85,90 GB)
> Bitmap 327701 BITS (CHUNKS), 325633 DIRTY (99,4%)
> 
> Filename /dev/sdc2
> Magic 6d746962
> Version 4
> UUID ae9bd4fe:994ce882:4fa035e6:8094fc1a
> events 892
> Events Cleared 892
> 
> State Out of date
> Chunksize 256 KB
> Daemon 5s flush period
> Write Mode Normal
> Sync Size 83891328 (80,01 GIB 85,90 GB)
> Bitmap 327701 BITS (CHUNKS), 325633 DIRTY (99,4%)
> 
> -----------------------------------------------------------------------------------------------------------------------------------
> 
> cat /sys/bplock/md0/md/array_state
> 
> inactive
> 
> 
> cat /sys/block/md0/md/degraded
> 
> cat /sys/block/md0/md/degraded: No such file or directory
> 
> 
> cat /sys/block/md0/md/dev-sda2/errors
> 
> 0
> 
> cat /sys/block/md0/md/dev-sda2/state
> 
> in_sync
> 
> 
> cat /sys/block/md0/md/dev-sdb2/errors
> 
> 24
> 
> 
> cat /sys/block/md0/md/dev-sdb2/state
> 
> in_sync
> 
> 
> cat /sys/block/md0/md/dev-sdc2/errors
> 
> 0
> 
> 
> cat /sys/block/md0/md/dev-sdc2/state
> 
> in_sync
> -----------------------------------------------------------------------------------------------------------------------------------
> 
> Thanks in advance.
> 
> -- 
> Jesus Bermudez Riquelme 
> 
> 
> Iten, S.L. 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Janek Kozicki                               http://janek.kozicki.pl/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Help!

[Neil Brown]

On Fri, 22 Oct 2010 16:51:20 +0200 (CEST)
Jesús Bermúdez <jbermudez@iten.es> wrote:

> Hello all,
> 
> if you could help us, for we are completely desperated...
> 
> We have a raid5 with 3 disks that got out of sync due to a power failure. After tried to assemble (with mdadm --assemble --force /dev/md0) it says:
> 
> md: md0 stopped mdbind sdb2 bind sda2 bind sdc2
> 
> md: md0: array is not clean starting background reconstruction
> 
> raid 5  device sdc2 operational as raid disk 0
>     device sda2 operational as raid disk 2
>     device sdb2 operational as raid disk 1
> 
> allocated 32kb for md0
> 
> raid level 5 set md0 active with 3 out 3 devices algorithm 0
> 
> raid 5 conf printout
> 
> rd:3 wd:3
> 
> disk 0,0:1 /dev/sdc2
> disk 1,0:1 /dev/sdb2
> disk 2,0:1 /dev/sda2
> 
> md0: bitmap file is out of date 892893
> forcing full recovery
> 
> md0: bitmap file is out of date doing full recovery
> 
> md0: bitmap initialisation failed: -5

This (the "-5") strongly suggests that we got an error when trying to write to
the bitmap.  But such errors normally appear in the kernel logs, yet you
don't report any.

Is this still a problem for you or have you found a solution?

You probably need to assemble the array without the device which is suffering
the write errors.

NeilBrown


> 
> md0: failed to create bitmap (-5)
> 
> md: pers->run() failed
> 
> mdadm: failed to run _array /dev/md0: input / output error
> 
> Tried to stop the array and reassemble it with:
> 
> mdadm --assemble --force --scan
> mdadm --assemble --force --scan /dev/md0 /dev/sda2 /dev/sdb2 /dev/sdc2
> mdadm --assemble --force --run /dev/md0 /dev/sda2 /dev/sdb2
> mdadm --assemble --force --run /dev/md0 /dev/sda2 /dev/sdc2
> mdadm --assemble --force --run /dev/md0 /dev/sdb2 /dev/sdc2
> 
> Tried to solve the bitmap problem with:
> 
> mdadm --grow /dev/md0 --bitmap=none
> mdadm --grow /dev/md0 --bitmap=internal
> mdadm --grow /dev/md0 --bitmap=none --force
> mdadm --grow /dev/md0 --bitmap=internal --force
> 
> Tried to fake the 'clean' status of the array with:
> 
> echo "clean" > /sys/block/md0/md/array_state
> 
> Tried to boot the array from grub with:
> 
>     md-mod.start_dirty_degraded=1
> 
> None of these commands have worked. Here are the details of the array and everyone of the disks:
> 
> -----------------------------------------------------------------------------------------------------------------------------------
> mdadm -D /dev/md0
> 
> dev/md0
> version: 01.00.03
> creation time: august 28 18:58:39 2009
> raid level: raid5
> used dev size 83891328 (80:01 hid 85:90 gdb)
> raid devices: 3
> total drives: 3
> preferred minor: 0
> persistent: superblock is persistent
> update time: tue oct 19 15:09 2010
> Status: active, not started
> Active devices: 3
> Working devices: 3
> Failed devices: 0
> Spare device: 0
> layout: left assimetric
> chunk size: 128k
> name: 0
> 
> UUID: ae9bd4fe:994ce882:4fa035e6:8094fc1a
> events: 893
> 
>     Number   Major   Minor   RaidDevice State
>     0    8    34    0    active sync /dev/sdc2
>     1    8    18    1    active sync /dev/sdb2
>     3    8    2    2    active sync /dev/sda2
> 
> -----------------------------------------------------------------------------------------------------------------------------------
> mdadm --examine /dev/sd[abc]2
> 
> 
> /dev/sda2:
> 
> Magic:a92b4efc
> Version:1,0
> Featura Map:0x1
> Array UUID:ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Name:0
> Creation Time:Fri Aug 28 18:58:39 2009
> Raid Level:Raid5
> Raid Devices:3:Avail Dev Size:167782712 (80,01GIB 85,90 GB)
> Array Size:335565312 (160,01 GIB 171,81 GB)
> Used Dev Size:167782656 (80,01 GIB 85,90GB)
> Super Offset:167782840 Sectors
> State:Active
> Device UUID:bbc156a7:6f3af82d:94714923:e212967a
> Internal Bitmap:-81 sectors from superblock
> Update Time:re Oct 19 15:49:08 2010
> Checksum:54a35562 - correct
> Events:893
> Layout:left-asymmetric
> Chunk Size:128K
> Array Slot:3 (0. 1, failed, 2)
> Array State:uuU 1 failed
> 
> 
> 
> /dev/sdb2:
> 	
> 
> Magic:a92b4efc
> Version:1,0
> Feature Map:0x1
> Array UUID:ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Name:0
> Creation Time:Fri Aug 28 18:58:39 2009
> Raid Level:raid5
> Raid Devices:3
> Avail Dev Size:167782712 (80,01 GIB 85,90 GB)
> Array Size:335565312 (160,01 GIB 171,81 GB)
> Used Dev Size:167782656 (80,01 GIB 85,90 GB)
> Super Offset:167782840 sectors
> State:Active
> Device UUID:d067101e:19056fdd:6b6e58fc:92128788
> Internal Bimap:-81 sectors from superblock
> Update Time:Tue Oct 19 15:49:08 2010
> Checksum:61d3c2bf
> Events:893
> Layout:left-asymmetric
> Chunk Size:128k
> Array Slot:1 (0,  1, failed, 2)
> Array State:uUu 1 failed
> 
> /dev/sdc2:
> 	
> Magic:a92b4efc
> Version:1,0
> Featura Map:0x1
> Array UUID:ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Name:0
> Creation Time:Fri Aug 28 18:58:39 2009
> Raid Level:raid5
> Raid Devices:3
> Avail Dev Size:167782712 (80,01 GIB 85,90 GB)
> Array Size:335565312 (160,01 GIB 171,81 GB)
> Used Dev Size:167782656 (80,01 GIB 85,90 GB)
> Super Offset:167782840 sectors
> State:active
> Device UUID:0a1c2c74:04b9187f:6ab6b5cb:894d8b38
> Internal Bimap:-81 sectos from superblock
> Update Time:Tue Oct 19 15:49:08 2010
> Checksum:d8faadc0 - correct
> Events:893
> Layout:left-asymmetric
> Chunk Size:128K
> Array Slot:0 (0, 1, failed, 2)
> Array State:Uuu 1 failed
> 
> -----------------------------------------------------------------------------------------------------------------------------------
> 
> mdadm --examine-bitmap /dev/sd[abc]2
> 	
> Filename /dev/sda2
> 
> Magic 6d746962
> Version 4
> UUID ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Events 892
> Events Cleared 892
> State Out of date
> Chunksize 256KB
> Daemon 5s flush period
> Write Mode Normal
> Sync Size 83891328 (80,01 GIB 85,90 GB)
> Bitmap 327701 BITS (CHUNKS), 325633 DIRTY (99,4%)
> 
> Filename /dev/sdb2
> 
> Magic 6d746962
> Version 4
> UUID ae9bd4fe:994ce882:4fa035e6:8094fc1a
> Events 892
> Events Cleared 892
> State Out of date
> Chunksize 256KB
> Daemon 5s flush period
> Write Mode Normal
> Sync Size 83891328 (80,01 GIB 85,90 GB)
> Bitmap 327701 BITS (CHUNKS), 325633 DIRTY (99,4%)
> 
> Filename /dev/sdc2
> Magic 6d746962
> Version 4
> UUID ae9bd4fe:994ce882:4fa035e6:8094fc1a
> events 892
> Events Cleared 892
> 
> State Out of date
> Chunksize 256 KB
> Daemon 5s flush period
> Write Mode Normal
> Sync Size 83891328 (80,01 GIB 85,90 GB)
> Bitmap 327701 BITS (CHUNKS), 325633 DIRTY (99,4%)
> 
> -----------------------------------------------------------------------------------------------------------------------------------
> 
> cat /sys/bplock/md0/md/array_state
> 
> inactive
> 
> 
> cat /sys/block/md0/md/degraded
> 
> cat /sys/block/md0/md/degraded: No such file or directory
> 
> 
> cat /sys/block/md0/md/dev-sda2/errors
> 
> 0
> 
> cat /sys/block/md0/md/dev-sda2/state
> 
> in_sync
> 
> 
> cat /sys/block/md0/md/dev-sdb2/errors
> 
> 24
> 
> 
> cat /sys/block/md0/md/dev-sdb2/state
> 
> in_sync
> 
> 
> cat /sys/block/md0/md/dev-sdc2/errors
> 
> 0
> 
> 
> cat /sys/block/md0/md/dev-sdc2/state
> 
> in_sync
> -----------------------------------------------------------------------------------------------------------------------------------
> 
> Thanks in advance.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

help!

[Angel Fish]

Hi,
I'm new to this mail list. And I want to touch the linux kernel. But I
can't find way to start.
Can anyone help to give me some advice?

Thanks
Angel Fish

Re: help!

[Ben Nizette]

On 22/04/2010, at 3:44 PM, Angel Fish wrote:

> Hi,
> I'm new to this mail list. And I want to touch the linux kernel. But I
> can't find way to start.
> Can anyone help to give me some advice?

kernelnewbies.org :-)

	--Ben.

> 
> Thanks
> Angel Fish
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

help!!

[Rohit Gupta]

Hello
m a fresher and assigned to a task to implement iptables for OS 20, which is
having no kernel supported tcp/ip stack and tcp/ip stack is implemented in
it by external file system now i have to implement iptables and netfilter in
it so plz guide me how to do it, as it is very necessary.
plz help me

Re: help!!

[Patrick McHardy]

Rohit Gupta wrote:
> Hello
> m a fresher and assigned to a task to implement iptables for OS 20, which is
> having no kernel supported tcp/ip stack and tcp/ip stack is implemented in
> it by external file system now i have to implement iptables and netfilter in
> it so plz guide me how to do it, as it is very necessary.
> plz help me


Please stop annoying people directly with your stupid questions
and pick proper subject lines.

Help!

[Stephan Higuti]

Hello guys....
I have a question about PREROUTING and POSTROUTING.
I'm making a new firewall script.....
In this script, i put some PREROUTING rules , ex:

####################### Apache ##########################
iptables -t nat -A PREROUTING -d 200.xxx.yyy.zzz -p tcp --dport 80 -j
DNAT --to-destination 192.168.23.7:80

But i need to put some POSTROUTING rules to this?
My situation: My firewall will reply for 4 differents Ip's (reals) ,
one for apache , other for e-mail server, etc............
This PREROUTING rule get a pack that come from internet to a IP "x" ,
and i want that all that incoming to this ip , to be forward to my
internal ip.
So , i think that PREROUTING rules its right... but i dont if i need
to create a POSTROUTING for this.....
Waiting Help....

p.s.:* Sorry for my bad, bad english   =D

Cheers

-- 
---------------------------------------------------------------------
Stephan Higuti
MSN: higutisam@hotmail.com
Email: higuti@fai.com.br
---------------------------------------------------------------------

Re: Help!

[Stephan Higuti]

thank'z Manish!

But i dont understant what you mean here:

> In ur scenario u will require only PREROUTING rule, but if want to
> access internet behind ur friewall, then need the POSTROUTING rule
> also. Choice is URs.

If i want that my servers access internet?

On 6/1/06, manish Jamwal <manish.jamwal@gmail.com> wrote:
> Hi
> When the server's r behind the firewall, u only need PREROUTING rule
> with target as DNAT.
> The POSTROUTING rule is required when ur traffic will be outwards,
> means u access the server's which are on ur WAN side.
> In ur scenario u will require only PREROUTING rule, but if want to
> access internet behind ur friewall, then need the POSTROUTING rule
> also. Choice is URs.
> This information is as per my knowledge. :)
> Manish
>
> On 6/1/06, Stephan Higuti <higuti.sam@gmail.com> wrote:
> > Hello guys....
> > I have a question about PREROUTING and POSTROUTING.
> > I'm making a new firewall script.....
> > In this script, i put some PREROUTING rules , ex:
> >
> > ####################### Apache ##########################
> > iptables -t nat -A PREROUTING -d 200.xxx.yyy.zzz -p tcp --dport 80 -j
> > DNAT --to-destination 192.168.23.7:80
> >
> > But i need to put some POSTROUTING rules to this?
> > My situation: My firewall will reply for 4 differents Ip's (reals) ,
> > one for apache , other for e-mail server, etc............
> > This PREROUTING rule get a pack that come from internet to a IP "x" ,
> > and i want that all that incoming to this ip , to be forward to my
> > internal ip.
> > So , i think that PREROUTING rules its right... but i dont if i need
> > to create a POSTROUTING for this.....
> > Waiting Help....
> >
> > p.s.:* Sorry for my bad, bad english   =D
> >
> > Cheers
> >
> > --
> > ---------------------------------------------------------------------
> > Stephan Higuti
> > MSN: higutisam@hotmail.com
> > Email: higuti@fai.com.br
> > ---------------------------------------------------------------------
> >
> >
>


-- 
---------------------------------------------------------------------
Stephan Higuti
MSN: higutisam@hotmail.com
Email: higuti@fai.com.br

Técnico em Informática
Adm servidores Linux
FAI - Faculdades Adamantinenses Integradas
---------------------------------------------------------------------

RE: Help!

[Sietse van Zanen]

You are doing it exactly as it should be done.
 
DNAT rules go to PREROUTING CHAIN (as you first want to set the new destination and the do routing)
SNAT rules go to POSTROUTING (usually, as it wouldn't really matter where they go, unless you do source routing).
 
Ofcourse you will need to ACCEPT the connections in your filter table too.
 
-Sietse

________________________________

From: netfilter-bounces@lists.netfilter.org on behalf of Stephan Higuti
Sent: Thu 01-Jun-06 13:53
To: netfilter@lists.netfilter.org
Subject: Help!



Hello guys....
I have a question about PREROUTING and POSTROUTING.
I'm making a new firewall script.....
In this script, i put some PREROUTING rules , ex:

####################### Apache ##########################
iptables -t nat -A PREROUTING -d 200.xxx.yyy.zzz -p tcp --dport 80 -j
DNAT --to-destination 192.168.23.7:80

But i need to put some POSTROUTING rules to this?
My situation: My firewall will reply for 4 differents Ip's (reals) ,
one for apache , other for e-mail server, etc............
This PREROUTING rule get a pack that come from internet to a IP "x" ,
and i want that all that incoming to this ip , to be forward to my
internal ip.
So , i think that PREROUTING rules its right... but i dont if i need
to create a POSTROUTING for this.....
Waiting Help....

p.s.:* Sorry for my bad, bad english   =D

Cheers

--
---------------------------------------------------------------------
Stephan Higuti
MSN: higutisam@hotmail.com
Email: higuti@fai.com.br
---------------------------------------------------------------------

Re: Help!

[Stephan Higuti]

thankz for help guys!
So , its right my rule?
Anyway... look this image:
http://img180.imageshack.us/my.php?image=firewallsemip2ok.jpg

My eth0 reply for 4 reals ip's...
And forward the packs to my servers......... so , PREROUTING its the
right way to do this?

Thank's a lot!

On 6/1/06, Sietse van Zanen <sietse@wizdom.nu> wrote:
> You are doing it exactly as it should be done.
>
> DNAT rules go to PREROUTING CHAIN (as you first want to set the new destination and the do routing)
> SNAT rules go to POSTROUTING (usually, as it wouldn't really matter where they go, unless you do source routing).
>
> Ofcourse you will need to ACCEPT the connections in your filter table too.
>
> -Sietse
>
> ________________________________
>
> From: netfilter-bounces@lists.netfilter.org on behalf of Stephan Higuti
> Sent: Thu 01-Jun-06 13:53
> To: netfilter@lists.netfilter.org
> Subject: Help!
>
>
>
> Hello guys....
> I have a question about PREROUTING and POSTROUTING.
> I'm making a new firewall script.....
> In this script, i put some PREROUTING rules , ex:
>
> ####################### Apache ##########################
> iptables -t nat -A PREROUTING -d 200.xxx.yyy.zzz -p tcp --dport 80 -j
> DNAT --to-destination 192.168.23.7:80
>
> But i need to put some POSTROUTING rules to this?
> My situation: My firewall will reply for 4 differents Ip's (reals) ,
> one for apache , other for e-mail server, etc............
> This PREROUTING rule get a pack that come from internet to a IP "x" ,
> and i want that all that incoming to this ip , to be forward to my
> internal ip.
> So , i think that PREROUTING rules its right... but i dont if i need
> to create a POSTROUTING for this.....
> Waiting Help....
>
> p.s.:* Sorry for my bad, bad english   =D
>
> Cheers
>
> --
> ---------------------------------------------------------------------
> Stephan Higuti
> MSN: higutisam@hotmail.com
> Email: higuti@fai.com.br
> ---------------------------------------------------------------------
>
>
>
>


-- 
---------------------------------------------------------------------
Stephan Higuti
MSN: higutisam@hotmail.com
Email: higuti@fai.com.br

Técnico em Informática
Adm servidores Linux
FAI - Faculdades Adamantinenses Integradas
---------------------------------------------------------------------

Re: help!

[Andrew Burgess]

>> >I had an mdadm device running fine, and had created my own scripts for 
>> >shutting it down and such. I upgraded my distro, and all of a sudden it 
>> >decided to start initializing md devices on it's own, which include one 
>> >that I want removed.
>>
>They were indeed set to raid autodetect. I was unaware of what that 
>actually did, I think I must have followed that step in a how-to when I 
>originally set it up. The odd thing is that these are the partition 
>pairs that were being mounted:
>sda sdb
>sda1 sdb1
>sdc1 sdd1
>The last 2 are the ones I actually wanted, but the first one was 
>something I had done when I was first playing around with it, if memory 
>serves me correct. Is that possible, or does it point to some other issue?

If changing the partition type does not work then you might try
zeroing the superblock with 'mdadm --zero-superblock /dev/sda'
etc.

AFAIK the superblock and the mdadm.conf file are mdadms only
information sources. Remove them both and it should be impossible
for the unwanted raid devices to start.

A funny thing here is that I believe the superblock for sda and
sda1 are in exactly the same place, at the end of the disk, so I
can't see how it would find two different raid devices. What
version superblocks are you using? I think v1 superblocks are at
the beginning of the device and I'm not sure if the first disk
block for sda is the same as the first block for sda1...

HTH (and it could be all wrong)

help!

[Shane Bishop]

I had an mdadm device running fine, and had created my own scripts for 
shutting it down and such. I upgraded my distro, and all of a sudden it 
decided to start initializing md devices on it's own, which include one 
that I want removed. The one that should be removed is throwing off the 
numbering, otherwise I wouldn't care so much. There's nothing in 
mdadm.conf, so I can only assume it's something with the kernel driver? 
Any help would be appreciated.

Shane Bishop

Re: help!

[Carlos Carvalho]

Shane Bishop (sbishop@trinitybiblecollege.edu) wrote on 14 November 2005 11:20:
 >I had an mdadm device running fine, and had created my own scripts for 
 >shutting it down and such. I upgraded my distro, and all of a sudden it 
 >decided to start initializing md devices on it's own, which include one 
 >that I want removed.

Probably the filesystem type in the partition table is set to raid
autodetect (fd). Try changing it to something else, for example 83.
Note that these are hexadecimal numbers.

Re: help!

[Shane Bishop]

Carlos Carvalho wrote:

>Shane Bishop (sbishop@trinitybiblecollege.edu) wrote on 14 November 2005 11:20:
> >I had an mdadm device running fine, and had created my own scripts for 
> >shutting it down and such. I upgraded my distro, and all of a sudden it 
> >decided to start initializing md devices on it's own, which include one 
> >that I want removed.
>
>Probably the filesystem type in the partition table is set to raid
>autodetect (fd). Try changing it to something else, for example 83.
>Note that these are hexadecimal numbers.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>  
>
They were indeed set to raid autodetect. I was unaware of what that 
actually did, I think I must have followed that step in a how-to when I 
originally set it up. The odd thing is that these are the partition 
pairs that were being mounted:
sda sdb
sda1 sdb1
sdc1 sdd1
The last 2 are the ones I actually wanted, but the first one was 
something I had done when I was first playing around with it, if memory 
serves me correct. Is that possible, or does it point to some other issue?

Shane

RE: Help!!!

[Baake, Matthias]

hi

maybe your workstation is starting the connections and the packets that you see are just the return packets?

/matthias

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org
> [mailto:netfilter-bounces@lists.netfilter.org]On Behalf Of radu
> Sent: Thursday, June 23, 2005 1:51 PM
> To: netfilter@lists.netfilter.org
> Subject: Help!!!
> 
> 
> Hello all,
> 
>       My networck config:
> 
>   Internet -> linux box -> My PC(192.168.50.101)
> 
>   linux box
>   eth0 local 192.168.50.0/24
>   eth1 Internet
>   
>   my iptables config:
> 
> iptables -P FORWARD DROP
> iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 4662 -j 
> DNAT --to 192.168.50.101
> iptables -I FORWARD  -d 192.168.50.101 -p tcp --dport 4662 -j ACCEPT
> iptables -I FORWARD -i eth1 -o eth0 -m state --state 
> ESTABLISHED,RELATED -j ACCEPT
> iptables -I FORWARD -s 192.168.50.101 -j ACCEPT
> iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE
>   
> why I'm receiving on my PC  packages  with external ip on
> 4690,4544,4581.. ports???
> 
> -- 
> Best regards,
>  Radu                          mailto:radu@adm.utm.md
> 
> 
> 

Help!!!

[radu]

Hello all,

      My networck config:

  Internet -> linux box -> My PC(192.168.50.101)

  linux box
  eth0 local 192.168.50.0/24
  eth1 Internet
  
  my iptables config:

iptables -P FORWARD DROP
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 4662 -j DNAT --to 192.168.50.101
iptables -I FORWARD  -d 192.168.50.101 -p tcp --dport 4662 -j ACCEPT
iptables -I FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -I FORWARD -s 192.168.50.101 -j ACCEPT
iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE
  
why I'm receiving on my PC  packages  with external ip on
4690,4544,4581.. ports???

-- 
Best regards,
 Radu                          mailto:radu@adm.utm.md

Re: Help!!!

[/dev/rob0]

On Thursday 23 June 2005 06:50, radu wrote:
> why I'm receiving on my PC  packages  with external ip on
> 4690,4544,4581.. ports???

That would be me. I was trying to lure you into posting something on 
this list. ;)

>   Internet -> linux box -> My PC(192.168.50.101)
>
>   linux box
>   eth0 local 192.168.50.0/24
>   eth1 Internet
>
>   my iptables config:
>
> iptables -P FORWARD DROP

good

> iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 4662 -j DNAT
> --to 192.168.50.101

4662/tcp packet arriving at the external interface should have their 
destination changed to Radu's computer ...

> iptables -I FORWARD  -d 192.168.50.101 -p tcp 
> --dport 4662 -j ACCEPT

... and those packets should be accepted.

> iptables -I FORWARD -i eth1 -o eth0 -m state 
> --state ESTABLISHED,RELATED -j ACCEPT

Any replies to established or related connections arriving at the 
external interface, destined to the internal interface, should be 
accepted.

This is surely the rule letting those in. Check the connection tracking 
table when you see them come in.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Help!!!

[Jason Opperisano]

On Thu, Jun 23, 2005 at 02:50:54PM +0300, radu wrote:
> Hello all,
> 
>       My networck config:
> 
>   Internet -> linux box -> My PC(192.168.50.101)
> 
>   linux box
>   eth0 local 192.168.50.0/24
>   eth1 Internet
>   
>   my iptables config:
> 
> iptables -P FORWARD DROP
> iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 4662 -j DNAT --to 192.168.50.101
> iptables -I FORWARD  -d 192.168.50.101 -p tcp --dport 4662 -j ACCEPT
> iptables -I FORWARD -i eth1 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -I FORWARD -s 192.168.50.101 -j ACCEPT
> iptables -t nat -I POSTROUTING -o eth1 -j MASQUERADE

a cleaned-up version of your script:

  iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 4662 \
    -j DNAT --to 192.168.50.101
  iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

  iptables -P FORWARD DROP
  iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
  iptables -A FORWARD -p tcp -d 192.168.50.101 --dport 4662 -j ACCEPT
  iptables -A FORWARD -s 192.168.50.101 -j ACCEPT

-j

--
"Meg: Oh no! I'm missing the news!
 Peter: We all miss The News, Meg, but Huey Lewis needs time to create,
 and we need to be patient."
        --Family Guy

help?

[Claudio Destri]

I have installed lm_sensors on a dual Athlon MP2200+ Tyan motherboard.
A Winbond chip is detected and this is the evidently wrong output of 
sensors:

w83627hf-i2c-0-2c
Adapter: SMBus AMD7X6 adapter at 80e0
Algorithm: Non-I2C SMBus adapter
VCore 1:   +1.66 V  (min =  +1.48 V, max =  +1.80 V)              
VCore 2:   +1.66 V  (min =  +1.48 V, max =  +1.80 V)              
+3.3V:     +3.29 V  (min =  +2.97 V, max =  +3.63 V)              
+5V:       +4.89 V  (min =  +4.50 V, max =  +5.48 V)              
+12V:      +9.42 V  (min = +10.79 V, max = +13.11 V)              
-12V:     -12.29 V  (min = -13.21 V, max = -10.90 V)              
-5V:       +0.01 V  (min =  -5.51 V, max =  -4.51 V)              
V5SB:      +5.38 V  (min =  +4.50 V, max =  +5.48 V)              
VBat:      +3.28 V  (min =  +2.70 V, max =  +3.29 V)              
fan1:     2721 RPM  (min = 3000 RPM, div = 2)                     
fan2:     2848 RPM  (min = 3000 RPM, div = 2)                     
fan3:        0 RPM  (min = 1500 RPM, div = 4)                     
temp1:       +67?C  (limit =  +60?C, hysteresis =  +50?C) sensor = 
PII/Celeron diode           
temp2:      +1.5?C  (limit =  +60?C, hysteresis =  +50?C) sensor = 
PII/Celeron diode           
temp3:      +3.5?C  (limit =  +60?C, hysteresis =  +50?C) sensor = 
PII/Celeron diode           
vid:       +1.65 V
alarms:   Chassis intrusion detection                      ALARM
beep_enable:
          Sound alarm disabled


What should I do? Perhaps changing from "PII/Celeron diode" according to 
the suggestion in /usr/share/doc/lm_sensors-2.6.3/doc/chips/w83781d 

        sensor[1-3]: (782d/783s only)
          Controls the sensor type. To change to a different
          sensor type, for example, do 'echo 2 > sensor1'.
          Valid values:
               1: Pentium II / Celeron diode
               2: 2N3904 Transistor in a diode configuration
            3435: Thermistor with Beta = 3435. Beta is a measure
                  of sensitivity to temperature.
 

But I haven't quite understood how.

-- 
			CLAUDIO DESTRI   Claudio.Destri@mib.infn.it
                        DIPARTIMENTO DI FISICA G. OCCHIALINI,
                        UNIVERSITA` MILANO-BICOCCA
                        PIAZZA DELLA SCIENZA 3, 20126 MILANO
                        tel: (39)(2)64482539  fax: (39)(2)64482585

help?

[Jean Delvare]

> I have installed lm_sensors on a dual Athlon MP2200+ Tyan motherboard.
> A Winbond chip is detected and this is the evidently wrong output of 
> sensors:
> 
> w83627hf-i2c-0-2c
> Adapter: SMBus AMD7X6 adapter at 80e0
> Algorithm: Non-I2C SMBus adapter
> VCore 1:   +1.66 V  (min =  +1.48 V, max =  +1.80 V)              
> VCore 2:   +1.66 V  (min =  +1.48 V, max =  +1.80 V)              
> +3.3V:     +3.29 V  (min =  +2.97 V, max =  +3.63 V)              
> +5V:       +4.89 V  (min =  +4.50 V, max =  +5.48 V)              
> +12V:      +9.42 V  (min = +10.79 V, max = +13.11 V)              
> -12V:     -12.29 V  (min = -13.21 V, max = -10.90 V)              
> -5V:       +0.01 V  (min =  -5.51 V, max =  -4.51 V)              
> V5SB:      +5.38 V  (min =  +4.50 V, max =  +5.48 V)              
> VBat:      +3.28 V  (min =  +2.70 V, max =  +3.29 V)              
> fan1:     2721 RPM  (min = 3000 RPM, div = 2)                     
> fan2:     2848 RPM  (min = 3000 RPM, div = 2)                     
> fan3:        0 RPM  (min = 1500 RPM, div = 4)                     
> temp1:       +67?C  (limit =  +60?C, hysteresis =  +50?C) sensor = 
> PII/Celeron diode           
> temp2:      +1.5?C  (limit =  +60?C, hysteresis =  +50?C) sensor = 
> PII/Celeron diode           
> temp3:      +3.5?C  (limit =  +60?C, hysteresis =  +50?C) sensor = 
> PII/Celeron diode           
> vid:       +1.65 V
> alarms:   Chassis intrusion detection                      ALARM
> beep_enable:
>           Sound alarm disabled

Well, it's not that wrong. The incorrect values may just mean you don't
have the sensor and you have to ignore the value. Having a look "in the
BIOS" sometimes show which sensors your motherboard is supposed to have.

> What should I do? Perhaps changing from "PII/Celeron diode" according
> to the suggestion in /usr/share/doc/lm_sensors-2.6.3/doc/chips/w83781d
> 
>         sensor[1-3]: (782d/783s only)
>           Controls the sensor type. To change to a different
>           sensor type, for example, do 'echo 2 > sensor1'.
>           Valid values:
>                1: Pentium II / Celeron diode
>                2: 2N3904 Transistor in a diode configuration
>             3435: Thermistor with Beta = 3435. Beta is a measure
>                   of sensitivity to temperature.
> 
> But I haven't quite understood how.

You have to edit /etc/sensors.conf. Look for "w83627hf" and you should
find where to change it a few dozen lines below. However, it is supposed
to work with 782d/783s only. You still can give it a try, though.

If it doesn't work, you may just want to suppress the output for values
that don't make a sense for you. To do this, you'll have to add "ignore"
lines in /etc/sensors.conf. For exemple, "ignore temp3" will remove the
"temp3" line. Just make sure you add the line in the right section of
the config file, or it won't work.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

help?

[Claudio Destri]

Attached is the output of decode-dimms.pl
Just to see if I understand anything of all this: are these two eeprom
chips the memory banks holding the programs that run the physical sensors?
 

-- 
			CLAUDIO DESTRI   Claudio.Destri@mib.infn.it
                        DIPARTIMENTO DI FISICA G. OCCHIALINI,
                        UNIVERSITA` MILANO-BICOCCA
                        PIAZZA DELLA SCIENZA 3, 20126 MILANO
                        tel: (39)(2)64482539  fax: (39)(2)64482585
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decode.25116DEFANGED-html
Type: application/octet-stream
Size: 9742 bytes
Desc: 
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030301/1a7e9018/decode.obj

help?

[Mark D. Studebaker]

Your eeproms are DDR.
I don't know why they aren't recognized in 'sensors', unless your 'sensors' version
is 2.6.3 or older (we added DDR support in 2.6.4).
The eeproms are "serial presence detect" memory (one per DDR memory DIMM)
which store configuration data about your DDR.
They have nothing at all to do with your sensors other than they are on
the same I2C bus.


Claudio Destri wrote:
> Attached is the output of decode-dimms.pl
> Just to see if I understand anything of all this: are these two eeprom
> chips the memory banks holding the programs that run the physical sensors?
>  
> 

help?

[Claudio Destri]

On Fri, 28 Feb 2003, Jean Delvare wrote:

> 
> [PLEASE REPLY TO THE LIST, NOT TO ME ALONE]
> 

Sorry!

> As far as I know, the "BIOS" does just what we do with i2c/lm_sensors
> for Linux. I don't think there's anything like "reading data directly
> from the BIOS". If you don't have the same results between the BIOS and
> lm_sensors, then there's somethinhg wrong and it needs fixin'. There are
> two possibilities. Either the driver is OK but the resistors are
> different on this motherboard, so you have to tweak the formula to get
> the right value. Or the driver isn't working for you. Both cases,
> there's almost nothing we can do until you investigate and give us
> valuable information to start from (either from the motherboard docs or
> experimental). So, if you want us to fix the problem, please gather as
> much information as possible and let us know.
> 

I will try my best (which isn't much, though).

> > > You have to edit /etc/sensors.conf. Look for "w83627hf" and you
> > > should find where to change it a few dozen lines below. However, it
> > > is supposed to work with 782d/783s only. You still can give it a
> > > try, though.
> > 
> > I edited those lines but the readings do not change, including the 
> > statement that sensors are  PII Celeron diodes. 
> 
> Didn't you forget to issue a "sensors -s" (as root) after editing the
> config file?

I did not.

> It probably means that it doesn't recognize the kind of EEPROM it found.
> Usually, EEPROMS are found on memory chips. We've also seen proprietary
> EEPROMs on some laptops (namely Sony Vaio). Is this system a laptop (or
> a desktop of some brand)?

One is an assembled desktop with a Tyan motherboard, Others are
MicroStar motherboards in a custom cluster. I will look up the 
precise specs when I am back at the office.

> 
> You may want to dump the EEPROM's contents to guess what it may be. To
> do this, unload the eeprom module (rmmod eeprom), then run the following
> commands:
> 
> i2cdump 0 0x50
> i2cdump 0 0x51
> i2cdump 0 0x54
> 

It took me some time to do that because in my Red Hat 8.0 installation the
lm_sensors package does not provide the i2c utils. Thus I had to work
with the original most recent distributions i2c-2.7.0.tar.gz and
lm_sensors-2.7.0.tar.gz. But it was not easy either to get the
compilation right with my kernel 2.4.20-openmosix2smp. Most of all,
I could not get modules with the right kernelversion (the smp at the end 
was missing, in spite of all careful reading and tweaking of the 
Makefile). In any case I forced the modules into the kernel, since the 
mismatch is only apparent, and upon running 
  i2cdump 0 0x50
  i2cdump 0 0x51
this is what I got:


     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
00: 80 08 07 0d 0a 02 40 00 04 75 75 00 82 08 00 01    ??????@.?uu.??.?
10: 0e 04 0c 01 02 20 00 a0 75 00 00 50 3c 50 2d 40    ????? .?u..P<P-@
20: 90 90 50 50 00 00 00 00 00 00 00 00 00 00 00 00    ??PP............
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0    ...............?
40: 7f 7f 7f 0b 00 00 00 00 09 4d 32 55 35 31 32 36    ????....?M2U5126
50: 34 44 53 38 48 41 30 47 2d 37 35 00 00 02 28 00    4DS8HA0G-75..?(.
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................

Does it mean something to you?

-- 
			CLAUDIO DESTRI   Claudio.Destri@mib.infn.it
                        DIPARTIMENTO DI FISICA G. OCCHIALINI,
                        UNIVERSITA` MILANO-BICOCCA
                        PIAZZA DELLA SCIENZA 3, 20126 MILANO
                        tel: (39)(2)64482539  fax: (39)(2)64482585

help?

[Jean Delvare]

[PLEASE REPLY TO THE LIST, NOT TO ME ALONE]

> > Well, it's not that wrong. The incorrect values may just mean you
> > don't have the sensor and you have to ignore the value. Having a
> > look "in the BIOS" sometimes show which sensors your motherboard is
> > supposed to have.
> 
> Thank you for the swift answer.
> The BIOS says nothing but reports quite different values for
> temperatures and fan's rpms w.r.t. the sensors command. Also some
> voltage is off limits. By the way, is it conceivable to read data
> directly from the bios or is the bios completely inactive when the
> linux kernel runs? 

As far as I know, the "BIOS" does just what we do with i2c/lm_sensors
for Linux. I don't think there's anything like "reading data directly
from the BIOS". If you don't have the same results between the BIOS and
lm_sensors, then there's somethinhg wrong and it needs fixin'. There are
two possibilities. Either the driver is OK but the resistors are
different on this motherboard, so you have to tweak the formula to get
the right value. Or the driver isn't working for you. Both cases,
there's almost nothing we can do until you investigate and give us
valuable information to start from (either from the motherboard docs or
experimental). So, if you want us to fix the problem, please gather as
much information as possible and let us know.

> > You have to edit /etc/sensors.conf. Look for "w83627hf" and you
> > should find where to change it a few dozen lines below. However, it
> > is supposed to work with 782d/783s only. You still can give it a
> > try, though.
> 
> I edited those lines but the readings do not change, including the 
> statement that sensors are  PII Celeron diodes. 

Didn't you forget to issue a "sensors -s" (as root) after editing the
config file?

> By the way, sensors-detect says it find also some eeprom chips (and
> twice with the same confidence level 8 of the w83627hf. But when I
> insert the eeprom module in the kernel, noting is read:
> 
> eeprom-i2c-0-50
> Adapter: SMBus AMD7X6 adapter at 80e0
> Algorithm: Non-I2C SMBus adapter
> 
> eeprom-i2c-0-51
> Adapter: SMBus AMD7X6 adapter at 80e0
> Algorithm: Non-I2C SMBus adapter
> 
> eeprom-i2c-0-54
> Adapter: SMBus AMD7X6 adapter at 80e0
> Algorithm: Non-I2C SMBus adapter
> 
> Does that simply mean that sensors-detect is fooled or the problem is
> that no specifications are provided in /etc/sensors.conf? I have other
> dual motherboards in a cluster where only the eeprom and no w83627hf
> are reported by sensors-detect. 

It probably means that it doesn't recognize the kind of EEPROM it found.
Usually, EEPROMS are found on memory chips. We've also seen proprietary
EEPROMs on some laptops (namely Sony Vaio). Is this system a laptop (or
a desktop of some brand)?

You may want to dump the EEPROM's contents to guess what it may be. To
do this, unload the eeprom module (rmmod eeprom), then run the following
commands:

i2cdump 0 0x50
i2cdump 0 0x51
i2cdump 0 0x54

> Thank you again.

You're welcome.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

Help!

[Anirban Mukherjee]

Hi all,

I am doing a project on Ext2fs and Ext3fs and I require some materials on
the physical structure of Ext2fs.It would be very helpful if someone sends
me some information(or links where to find it) along with some general
stuff on Ext2fs and Ext3fs.

Thanks,
Anirban.

Re: Help!

[Matthew Wilcox]

On Fri, Feb 04, 2005 at 03:58:04PM +0530, Anirban Mukherjee wrote:
> I am doing a project on Ext2fs and Ext3fs and I require some materials on
> the physical structure of Ext2fs.It would be very helpful if someone sends
> me some information(or links where to find it) along with some general
> stuff on Ext2fs and Ext3fs.

"Please do my homework for me"

Did you even look in Documentation/filesystems/ext{2,3}.txt?

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Help!

[soar.wu]

[-- Attachment #1.1: Type: text/plain, Size: 2172 bytes --]

Clear DayHi,

I am very sorry to disturb you.
I have a problem.

We use the powerPC chip, though it is not your IBM chip.
It is Motorola MPC8260.
We have the HPI to the local bus of the MPC8260.

Firstly we will write data to the HPI,
then read data from the HPI to the SDRAM(this SDRAM is connected with 60x-BUS).
The last we will read the data from the SDRAM to compare the data which is write to HPI.

But we find it is different, there is a hop.
After we read out the data from SDRAM, we find there is a change.
e.g. the data which is write to the HPI is ordered by 1,2,3,4,5,6,7,8. 
but the data which is read out from HPI and store to SDRAM is 1,2,3,4,6,7,8,..

Then I modify the source codes as the follows:
void hpi_ul_memcpy_dsp2h(void *dest,U32 src_dsp_memory_addr, U32 count)
{
..............
for(i = 0; i < len ; i+=4)
0x9ee940 +0x074: li r0, 0x0 (0)
0x9ee944 +0x078: stw r0, 0x18(r31)
0x9ee948 +0x07c: lwz r0, 0x18(r31)
0x9ee94c +0x080: lwz r9, 0x1c(r31)
0x9ee950 +0x084: cmpl crf1, 0, r0, r9
0x9ee954 +0x088: bc 0xc, 0x4, hpi_ul_memcpy_dsp2h + 0x90
0x9ee958 +0x08c: b hpi_ul_memcpy_dsp2h + 0xcc
{
#if 0 /* the old source codes*/
*p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
p_cur++;
#else /* the new source codes*/
tmpReadRst = READ_UL_HPI_REG(UL_HPIDA_ADDR);
0x9ee95c +0x090: lis r9, 0x5200 (20992)
0x9ee960 +0x094: ori r9, r9, 0x8
0x9ee964 +0x098: lwz r0, 0x0(r9)
0x9ee968 +0x09c: stw r0, 0x24(r31)
*p_cur = tmpReadRst;
0x9ee96c +0x0a0: lwz r9, 0x14(r31)
0x9ee970 +0x0a4: lwz r0, 0x24(r31)
0x9ee974 +0x0a8: stw r0, 0x0(r9)
p_cur++;
0x9ee978 +0x0ac: lwz r9, 0x14(r31)
0x9ee97c +0x0b0: addi r0, r9, 0x4 (4)
0x9ee980 +0x0b4: or r9, r0, r0
0x9ee984 +0x0b8: stw r9, 0x14(r31)
#endif
}
..........
}
We find the problem is disappeared.

But I donot know the reason.
I only know something, like the data which is loaded by loading instruction to register, 
is valid only when the instruction is excuted after 2-clock-cycle

Do you tell me the reason??

Wait for your reply. 
Best Regards,
Soar Wu

Node B, 3G Department
UTStarcom (China) Inc.
Tel:(86-0755)26952899-4610
Email:soar.wu@utstar.com



[-- Attachment #1.2: Type: text/html, Size: 4389 bytes --]

[-- Attachment #2: Clear Day Bkgrd.JPG --]
[-- Type: image/jpeg, Size: 5675 bytes --]

Re: Help!

[Mark Chambers]

Clear Day>Firstly we will write data to the HPI,
>then read data from the HPI to the SDRAM(this SDRAM is connected with
60x-BUS).
>The last we will read the data from the SDRAM to compare the data which is
write >to HPI.

Can you show the entire source for hpi_ul_memcpy_dsp2h()?

Also, you say 'HPI' - are connected to a T.I. DSP?  Which one?

Mark Chambers

RE: Help!

[soar.wu]

[-- Attachment #1: Type: text/plain, Size: 2480 bytes --]


The attached file is the hpi_ul_memcpy_dsp2h() function.

Yes, the 'HPI' - are connected to a T.I. DSP, 6416 type.

About the HPI problem progress.
now we have the following resolve method:

1, If we use a temp variable to store the read out data, then store the data to SDRAM, it is OK, there is no hop.
     tmpReadRst = READ_UL_HPI_REG(UL_HPIDA_ADDR);
    *p_cur = tmpReadRst;
     p_cur++;

2, If we donot modify the source codes, but we use the optimization O3 to compile the source codes, it is OK.
	*p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
	p_cur++;

3, If we add a sync instruction to the source  codes, it is OK.
	*p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
            __asm__("  eieio; sync");
	p_cur++;

4, If we modify the BSP, update the memory operation option,
from :
PHYS_MEM_DESC sysPhysMemDesc [] =
{
...
    /*all the other small chip*/
    {
    (void *) 0x50000000,
    (void *) 0x50000000,
    0x08000000,     
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
    },
...
to:
PHYS_MEM_DESC sysPhysMemDesc [] =
{
...
    /*all the other small chip*/
    {
    (void *) 0x50000000,
    (void *) 0x50000000,
    0x08000000,     
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | VM_STATE_MASK_GUARDED,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT | VM_STATE_GUARDED
    },
...

We added the option VM_STATE_VM_MASK_GUARDED and VM_STATE_GUARDED,
still use the old source codes:
	*p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
	p_cur++;

Now We find there is no hop. It is OK


5, If we use the memory which is allocated by function cacheDmaMalloc(), 
the hop still exist, but the number of  hop is little than when we use malloc().

Do you tell me the reason??

Wait for your reply.

Best Regards,
Soar Wu

-----Original Message-----
From: Mark Chambers [mailto:markc@mail.com]
Sent: 2004年10月26日 22:13
To: soar.wu; linuxppc-embedded@ozlabs.org
Subject: Re: Help!


Clear Day>Firstly we will write data to the HPI,
>then read data from the HPI to the SDRAM(this SDRAM is connected with
60x-BUS).
>The last we will read the data from the SDRAM to compare the data which is
write >to HPI.

Can you show the entire source for hpi_ul_memcpy_dsp2h()?

Also, you say 'HPI' - are connected to a T.I. DSP?  Which one?

Mark Chambers

[-- Attachment #2: dsp2h.txt --]
[-- Type: text/plain, Size: 4031 bytes --]

void hpi_ul_memcpy_dsp2h(void *dest,U32 src_dsp_memory_addr, U32 count)
{
	0x9ee8bc       hpi_ul_memcpy_dsp2h:    stwu        r1, 0xffd0(r1)
	0x9ee8c0       +0x004:                 mfspr       r0, LR
	0x9ee8c4       +0x008:                 stw         r31, 0x2c(r1)
	0x9ee8c8       +0x00c:                 stw         r0, 0x34(r1)
	0x9ee8cc       +0x010:                 or          r31, r1, r1
	0x9ee8d0       +0x014:                 stw         r3, 0x8(r31)
	0x9ee8d4       +0x018:                 stw         r4, 0xc(r31)
	0x9ee8d8       +0x01c:                 stw         r5, 0x10(r31)
	U32 *p_cur = dest;
	0x9ee8dc       +0x020:                 lwz         r0, 0x8(r31)
	0x9ee8e0       +0x024:                 stw         r0, 0x14(r31)
	U32  i,len;
	U32 scraddr = src_dsp_memory_addr;
	0x9ee8e4       +0x028:                 lwz         r0, 0xc(r31)
	0x9ee8e8       +0x02c:                 stw         r0, 0x20(r31)
	
	len = DWORD_ALIGN(count);
	0x9ee8ec       +0x030:                 lwz         r9, 0x10(r31)
	0x9ee8f0       +0x034:                 addi        r0, r9, 0x3 (3)
	0x9ee8f4       +0x038:                 rlwinm      r9, r0, 0x1e, 2, 31
	0x9ee8f8       +0x03c:                 or          r0, r9, r9
	0x9ee8fc       +0x040:                 rlwinm      r9, r0, 0x2, 0, 29
	0x9ee900       +0x044:                 stw         r9, 0x1c(r31)

	HPI_UL_LOCK();	
	0x9ee904       +0x048:                 lis         r9, 0x9f (159)
	0x9ee908       +0x04c:                 addi        r11, r9, 0x6d8 (1752)
	0x9ee90c       +0x050:                 lwz         r3, 0x0(r11)
	0x9ee910       +0x054:                 li          r4, 0xffff (-1)
	0x9ee914       +0x058:                 bl          semTake

	

	WRITE_UL_HPI_REG(UL_HPIA_ADDR,scraddr);
	0x9ee918       +0x05c:                 lis         r9, 0x5200 (20992)
	0x9ee91c       +0x060:                 ori         r9, r9, 0x4
	0x9ee920       +0x064:                 lwz         r0, 0x20(r31)
	0x9ee924       +0x068:                 stw         r0, 0x0(r9)
	for(i = 0; i < len ; i+=4)
	0x9ee928       +0x06c:                 li          r0, 0x0 (0)
	0x9ee92c       +0x070:                 stw         r0, 0x18(r31)
	0x9ee930       +0x074:                 lwz         r0, 0x18(r31)
	0x9ee934       +0x078:                 lwz         r9, 0x1c(r31)
	0x9ee938       +0x07c:                 cmpl        crf1, 0, r0, r9
	0x9ee93c       +0x080:                 bc          0xc, 0x4, hpi_ul_memcpy_dsp2h + 0x88
	0x9ee940       +0x084:                 b           hpi_ul_memcpy_dsp2h + 0xbc
	{
		*p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
	0x9ee944       +0x088:                 lwz         r9, 0x14(r31)
	0x9ee948       +0x08c:                 lis         r11, 0x5200 (20992)
	0x9ee94c       +0x090:                 ori         r11, r11, 0x8
	0x9ee950       +0x094:                 lwz         r0, 0x0(r11)
	0x9ee954       +0x098:                 stw         r0, 0x0(r9)
		p_cur++;
	0x9ee958       +0x09c:                 lwz         r9, 0x14(r31)
	0x9ee95c       +0x0a0:                 addi        r0, r9, 0x4 (4)
	0x9ee960       +0x0a4:                 or          r9, r0, r0
	0x9ee964       +0x0a8:                 stw         r9, 0x14(r31)
	}

	HPI_UL_UNLOCK();	
	0x9ee978       +0x0bc:                 lis         r9, 0x9f (159)
	0x9ee97c       +0x0c0:                 addi        r11, r9, 0x6d8 (1752)
	0x9ee980       +0x0c4:                 lwz         r3, 0x0(r11)
	0x9ee984       +0x0c8:                 bl          semGive

	return;
	0x9ee988       +0x0cc:                 b           hpi_ul_memcpy_dsp2h + 0xd0
}
	0x9ee98c       +0x0d0:                 lwz         r11, 0x0(r1)
	0x9ee990       +0x0d4:                 lwz         r0, 0x4(r11)
	0x9ee994       +0x0d8:                 mtspr       LR, r0
	0x9ee998       +0x0dc:                 lwz         r31, 0xfffc(r11)
	0x9ee99c       +0x0e0:                 or          r1, r11, r11
	0x9ee9a0       +0x0e4:                 blr         

RE: Help!

[soar.wu]

DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzb2FyLnd1IFttYWlsdG86c29h
ci53dUB1dHN0YXIuY29tXQ0KU2VudDogMjAwNMTqMTDUwjI3yNUgMTE6NDgNClRvOiBNYXJrIENo
YW1iZXJzOyBsaW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnDQpTdWJqZWN0OiBSRTogSGVscCEN
Cg0KDQoNClRoZSBhdHRhY2hlZCBmaWxlIGlzIHRoZSBocGlfdWxfbWVtY3B5X2RzcDJoKCkgZnVu
Y3Rpb24uDQoNClllcywgdGhlICdIUEknIC0gYXJlIGNvbm5lY3RlZCB0byBhIFQuSS4gRFNQLCA2
NDE2IHR5cGUuDQoNCkFib3V0IHRoZSBIUEkgcHJvYmxlbSBwcm9ncmVzcy4NCm5vdyB3ZSBoYXZl
IHRoZSBmb2xsb3dpbmcgcmVzb2x2ZSBtZXRob2Q6DQoNCjEsIElmIHdlIHVzZSBhIHRlbXAgdmFy
aWFibGUgdG8gc3RvcmUgdGhlIHJlYWQgb3V0IGRhdGEsIHRoZW4gc3RvcmUgdGhlIGRhdGEgdG8g
U0RSQU0sIGl0IGlzIE9LLCB0aGVyZSBpcyBubyBob3AuDQogICAgIHRtcFJlYWRSc3QgPSBSRUFE
X1VMX0hQSV9SRUcoVUxfSFBJREFfQUREUik7DQogICAgKnBfY3VyID0gdG1wUmVhZFJzdDsNCiAg
ICAgcF9jdXIrKzsNCg0KMiwgSWYgd2UgZG9ub3QgbW9kaWZ5IHRoZSBzb3VyY2UgY29kZXMsIGJ1
dCB3ZSB1c2UgdGhlIG9wdGltaXphdGlvbiBPMyB0byBjb21waWxlIHRoZSBzb3VyY2UgY29kZXMs
IGl0IGlzIE9LLg0KCSpwX2N1ciA9IFJFQURfVUxfSFBJX1JFRyhVTF9IUElEQV9BRERSKTsNCglw
X2N1cisrOw0KDQozLCBJZiB3ZSBhZGQgYSBzeW5jIGluc3RydWN0aW9uIHRvIHRoZSBzb3VyY2Ug
IGNvZGVzLCBpdCBpcyBPSy4NCgkqcF9jdXIgPSBSRUFEX1VMX0hQSV9SRUcoVUxfSFBJREFfQURE
Uik7DQogICAgICAgICAgICBfX2FzbV9fKCIgIGVpZWlvOyBzeW5jIik7DQoJcF9jdXIrKzsNCg0K
NCwgSWYgd2UgbW9kaWZ5IHRoZSBCU1AsIHVwZGF0ZSB0aGUgbWVtb3J5IG9wZXJhdGlvbiBvcHRp
b24sDQpmcm9tIDoNClBIWVNfTUVNX0RFU0Mgc3lzUGh5c01lbURlc2MgW10gPQ0Kew0KLi4uDQog
ICAgLyphbGwgdGhlIG90aGVyIHNtYWxsIGNoaXAqLw0KICAgIHsNCiAgICAodm9pZCAqKSAweDUw
MDAwMDAwLA0KICAgICh2b2lkICopIDB4NTAwMDAwMDAsDQogICAgMHgwODAwMDAwMCwgICAgIA0K
ICAgIFZNX1NUQVRFX01BU0tfVkFMSUQgfCBWTV9TVEFURV9NQVNLX1dSSVRBQkxFIHwgVk1fU1RB
VEVfTUFTS19DQUNIRUFCTEUsDQogICAgVk1fU1RBVEVfVkFMSUQgICAgICB8IFZNX1NUQVRFX1dS
SVRBQkxFICAgICAgfCBWTV9TVEFURV9DQUNIRUFCTEVfTk9UDQogICAgfSwNCi4uLg0KdG86DQpQ
SFlTX01FTV9ERVNDIHN5c1BoeXNNZW1EZXNjIFtdID0NCnsNCi4uLg0KICAgIC8qYWxsIHRoZSBv
dGhlciBzbWFsbCBjaGlwKi8NCiAgICB7DQogICAgKHZvaWQgKikgMHg1MDAwMDAwMCwNCiAgICAo
dm9pZCAqKSAweDUwMDAwMDAwLA0KICAgIDB4MDgwMDAwMDAsICAgICANCiAgICBWTV9TVEFURV9N
QVNLX1ZBTElEIHwgVk1fU1RBVEVfTUFTS19XUklUQUJMRSB8IFZNX1NUQVRFX01BU0tfQ0FDSEVB
QkxFIHwgVk1fU1RBVEVfTUFTS19HVUFSREVELA0KICAgIFZNX1NUQVRFX1ZBTElEICAgICAgfCBW
TV9TVEFURV9XUklUQUJMRSAgICAgIHwgVk1fU1RBVEVfQ0FDSEVBQkxFX05PVCB8IFZNX1NUQVRF
X0dVQVJERUQNCiAgICB9LA0KLi4uDQoNCldlIGFkZGVkIHRoZSBvcHRpb24gVk1fU1RBVEVfVk1f
TUFTS19HVUFSREVEIGFuZCBWTV9TVEFURV9HVUFSREVELA0Kc3RpbGwgdXNlIHRoZSBvbGQgc291
cmNlIGNvZGVzOg0KCSpwX2N1ciA9IFJFQURfVUxfSFBJX1JFRyhVTF9IUElEQV9BRERSKTsNCglw
X2N1cisrOw0KDQpOb3cgV2UgZmluZCB0aGVyZSBpcyBubyBob3AuIEl0IGlzIE9LDQoNCg0KNSwg
SWYgd2UgdXNlIHRoZSBtZW1vcnkgd2hpY2ggaXMgYWxsb2NhdGVkIGJ5IGZ1bmN0aW9uIGNhY2hl
RG1hTWFsbG9jKCksIA0KdGhlIGhvcCBzdGlsbCBleGlzdCwgYnV0IHRoZSBudW1iZXIgb2YgIGhv
cCBpcyBsaXR0bGUgdGhhbiB3aGVuIHdlIHVzZSBtYWxsb2MoKS4NCg0KRG8geW91IHRlbGwgbWUg
dGhlIHJlYXNvbj8/DQoNCldhaXQgZm9yIHlvdXIgcmVwbHkuDQoNCkJlc3QgUmVnYXJkcywNClNv
YXIgV3UNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcmsgQ2hhbWJlcnMg
W21haWx0bzptYXJrY0BtYWlsLmNvbV0NClNlbnQ6IDIwMDTE6jEw1MIyNsjVIDIyOjEzDQpUbzog
c29hci53dTsgbGludXhwcGMtZW1iZWRkZWRAb3psYWJzLm9yZw0KU3ViamVjdDogUmU6IEhlbHAh
DQoNCg0KQ2xlYXIgRGF5PkZpcnN0bHkgd2Ugd2lsbCB3cml0ZSBkYXRhIHRvIHRoZSBIUEksDQo+
dGhlbiByZWFkIGRhdGEgZnJvbSB0aGUgSFBJIHRvIHRoZSBTRFJBTSh0aGlzIFNEUkFNIGlzIGNv
bm5lY3RlZCB3aXRoDQo2MHgtQlVTKS4NCj5UaGUgbGFzdCB3ZSB3aWxsIHJlYWQgdGhlIGRhdGEg
ZnJvbSB0aGUgU0RSQU0gdG8gY29tcGFyZSB0aGUgZGF0YSB3aGljaCBpcw0Kd3JpdGUgPnRvIEhQ
SS4NCg0KQ2FuIHlvdSBzaG93IHRoZSBlbnRpcmUgc291cmNlIGZvciBocGlfdWxfbWVtY3B5X2Rz
cDJoKCk/DQoNCkFsc28sIHlvdSBzYXkgJ0hQSScgLSBhcmUgY29ubmVjdGVkIHRvIGEgVC5JLiBE
U1A/ICBXaGljaCBvbmU/DQoNCk1hcmsgQ2hhbWJlcnMNCg==

RE: Help!

[soar.wu]

[-- Attachment #1: Type: text/plain, Size: 2851 bytes --]

Sorry for forget the attached file

-----Original Message-----
From: soar.wu [mailto:soar.wu@utstar.com]
Sent: 2004年10月27日 11:49
To: linuxppc-embedded@ozlabs.org
Subject: RE: Help!




-----Original Message-----
From: soar.wu [mailto:soar.wu@utstar.com]
Sent: 2004年10月27日 11:48
To: Mark Chambers; linuxppc-embedded@ozlabs.org
Subject: RE: Help!



The attached file is the hpi_ul_memcpy_dsp2h() function.

Yes, the 'HPI' - are connected to a T.I. DSP, 6416 type.

About the HPI problem progress.
now we have the following resolve method:

1, If we use a temp variable to store the read out data, then store the data to SDRAM, it is OK, there is no hop.
     tmpReadRst = READ_UL_HPI_REG(UL_HPIDA_ADDR);
    *p_cur = tmpReadRst;
     p_cur++;

2, If we donot modify the source codes, but we use the optimization O3 to compile the source codes, it is OK.
	*p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
	p_cur++;

3, If we add a sync instruction to the source  codes, it is OK.
	*p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
            __asm__("  eieio; sync");
	p_cur++;

4, If we modify the BSP, update the memory operation option,
from :
PHYS_MEM_DESC sysPhysMemDesc [] =
{
...
    /*all the other small chip*/
    {
    (void *) 0x50000000,
    (void *) 0x50000000,
    0x08000000,     
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
    },
...
to:
PHYS_MEM_DESC sysPhysMemDesc [] =
{
...
    /*all the other small chip*/
    {
    (void *) 0x50000000,
    (void *) 0x50000000,
    0x08000000,     
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | VM_STATE_MASK_GUARDED,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT | VM_STATE_GUARDED
    },
...

We added the option VM_STATE_VM_MASK_GUARDED and VM_STATE_GUARDED,
still use the old source codes:
	*p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
	p_cur++;

Now We find there is no hop. It is OK


5, If we use the memory which is allocated by function cacheDmaMalloc(), 
the hop still exist, but the number of  hop is little than when we use malloc().

Do you tell me the reason??

Wait for your reply.

Best Regards,
Soar Wu

-----Original Message-----
From: Mark Chambers [mailto:markc@mail.com]
Sent: 2004年10月26日 22:13
To: soar.wu; linuxppc-embedded@ozlabs.org
Subject: Re: Help!


Clear Day>Firstly we will write data to the HPI,
>then read data from the HPI to the SDRAM(this SDRAM is connected with
60x-BUS).
>The last we will read the data from the SDRAM to compare the data which is
write >to HPI.

Can you show the entire source for hpi_ul_memcpy_dsp2h()?

Also, you say 'HPI' - are connected to a T.I. DSP?  Which one?

Mark Chambers

[-- Attachment #2: dsp2h.txt --]
[-- Type: text/plain, Size: 4031 bytes --]

void hpi_ul_memcpy_dsp2h(void *dest,U32 src_dsp_memory_addr, U32 count)
{
	0x9ee8bc       hpi_ul_memcpy_dsp2h:    stwu        r1, 0xffd0(r1)
	0x9ee8c0       +0x004:                 mfspr       r0, LR
	0x9ee8c4       +0x008:                 stw         r31, 0x2c(r1)
	0x9ee8c8       +0x00c:                 stw         r0, 0x34(r1)
	0x9ee8cc       +0x010:                 or          r31, r1, r1
	0x9ee8d0       +0x014:                 stw         r3, 0x8(r31)
	0x9ee8d4       +0x018:                 stw         r4, 0xc(r31)
	0x9ee8d8       +0x01c:                 stw         r5, 0x10(r31)
	U32 *p_cur = dest;
	0x9ee8dc       +0x020:                 lwz         r0, 0x8(r31)
	0x9ee8e0       +0x024:                 stw         r0, 0x14(r31)
	U32  i,len;
	U32 scraddr = src_dsp_memory_addr;
	0x9ee8e4       +0x028:                 lwz         r0, 0xc(r31)
	0x9ee8e8       +0x02c:                 stw         r0, 0x20(r31)
	
	len = DWORD_ALIGN(count);
	0x9ee8ec       +0x030:                 lwz         r9, 0x10(r31)
	0x9ee8f0       +0x034:                 addi        r0, r9, 0x3 (3)
	0x9ee8f4       +0x038:                 rlwinm      r9, r0, 0x1e, 2, 31
	0x9ee8f8       +0x03c:                 or          r0, r9, r9
	0x9ee8fc       +0x040:                 rlwinm      r9, r0, 0x2, 0, 29
	0x9ee900       +0x044:                 stw         r9, 0x1c(r31)

	HPI_UL_LOCK();	
	0x9ee904       +0x048:                 lis         r9, 0x9f (159)
	0x9ee908       +0x04c:                 addi        r11, r9, 0x6d8 (1752)
	0x9ee90c       +0x050:                 lwz         r3, 0x0(r11)
	0x9ee910       +0x054:                 li          r4, 0xffff (-1)
	0x9ee914       +0x058:                 bl          semTake

	

	WRITE_UL_HPI_REG(UL_HPIA_ADDR,scraddr);
	0x9ee918       +0x05c:                 lis         r9, 0x5200 (20992)
	0x9ee91c       +0x060:                 ori         r9, r9, 0x4
	0x9ee920       +0x064:                 lwz         r0, 0x20(r31)
	0x9ee924       +0x068:                 stw         r0, 0x0(r9)
	for(i = 0; i < len ; i+=4)
	0x9ee928       +0x06c:                 li          r0, 0x0 (0)
	0x9ee92c       +0x070:                 stw         r0, 0x18(r31)
	0x9ee930       +0x074:                 lwz         r0, 0x18(r31)
	0x9ee934       +0x078:                 lwz         r9, 0x1c(r31)
	0x9ee938       +0x07c:                 cmpl        crf1, 0, r0, r9
	0x9ee93c       +0x080:                 bc          0xc, 0x4, hpi_ul_memcpy_dsp2h + 0x88
	0x9ee940       +0x084:                 b           hpi_ul_memcpy_dsp2h + 0xbc
	{
		*p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
	0x9ee944       +0x088:                 lwz         r9, 0x14(r31)
	0x9ee948       +0x08c:                 lis         r11, 0x5200 (20992)
	0x9ee94c       +0x090:                 ori         r11, r11, 0x8
	0x9ee950       +0x094:                 lwz         r0, 0x0(r11)
	0x9ee954       +0x098:                 stw         r0, 0x0(r9)
		p_cur++;
	0x9ee958       +0x09c:                 lwz         r9, 0x14(r31)
	0x9ee95c       +0x0a0:                 addi        r0, r9, 0x4 (4)
	0x9ee960       +0x0a4:                 or          r9, r0, r0
	0x9ee964       +0x0a8:                 stw         r9, 0x14(r31)
	}

	HPI_UL_UNLOCK();	
	0x9ee978       +0x0bc:                 lis         r9, 0x9f (159)
	0x9ee97c       +0x0c0:                 addi        r11, r9, 0x6d8 (1752)
	0x9ee980       +0x0c4:                 lwz         r3, 0x0(r11)
	0x9ee984       +0x0c8:                 bl          semGive

	return;
	0x9ee988       +0x0cc:                 b           hpi_ul_memcpy_dsp2h + 0xd0
}
	0x9ee98c       +0x0d0:                 lwz         r11, 0x0(r1)
	0x9ee990       +0x0d4:                 lwz         r0, 0x4(r11)
	0x9ee994       +0x0d8:                 mtspr       LR, r0
	0x9ee998       +0x0dc:                 lwz         r31, 0xfffc(r11)
	0x9ee99c       +0x0e0:                 or          r1, r11, r11
	0x9ee9a0       +0x0e4:                 blr         

Re: Help!

[Mark Chambers]

> Yes, the 'HPI' - are connected to a T.I. DSP, 6416 type.
>
> About the HPI problem progress.
> now we have the following resolve method:
>
> 1, If we use a temp variable to store the read out data, then store the
data to SDRAM, it is OK, there is no hop.
>      tmpReadRst = READ_UL_HPI_REG(UL_HPIDA_ADDR);
>     *p_cur = tmpReadRst;
>      p_cur++;
>
> 2, If we donot modify the source codes, but we use the optimization O3 to
compile the source codes, it is OK.
> *p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
> p_cur++;
>
> 3, If we add a sync instruction to the source  codes, it is OK.
> *p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
>             __asm__("  eieio; sync");
> p_cur++;
>
> 4, If we modify the BSP, update the memory operation option,
> from :
> PHYS_MEM_DESC sysPhysMemDesc [] =
> {
> ...
>     /*all the other small chip*/
>     {
>     (void *) 0x50000000,
>     (void *) 0x50000000,
>     0x08000000,
>     VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE |
VM_STATE_MASK_CACHEABLE,
>     VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
>     },
> ...
> to:
> PHYS_MEM_DESC sysPhysMemDesc [] =
> {
> ...
>     /*all the other small chip*/
>     {
>     (void *) 0x50000000,
>     (void *) 0x50000000,
>     0x08000000,
>     VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE
| VM_STATE_MASK_GUARDED,
>     VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT
| VM_STATE_GUARDED
>     },
> ...
>
> We added the option VM_STATE_VM_MASK_GUARDED and VM_STATE_GUARDED,
> still use the old source codes:
> *p_cur = READ_UL_HPI_REG(UL_HPIDA_ADDR);
> p_cur++;
>
> Now We find there is no hop. It is OK
>
>
> 5, If we use the memory which is allocated by function cacheDmaMalloc(),
> the hop still exist, but the number of  hop is little than when we use
malloc().
>
> Do you tell me the reason??
>

sysPhysMemDesc? This is VxWorks, not linux, right?  Well, the same general
points can be made, but this list is not the right one for VxWorks issues.

1) Even though the 8260 is cache-coherent you should make sure the MMU is
set up so the HPI space is non-cached.
2) In C code make sure the HPI space is declared as 'volatile' so the
compiler doesn't optimize out references to the address.
3) Remember that the HPI interface on the DSP is DMA driven and goes through
a FIFO, so that writes to DSP memory have a delay before they actually
appear in DSP memory.  And don't forget to look at cache issues on the DSP
side.  Your problem may actually be on the DSP side and your various fixes
are just introducing enough delay for things to complete on the DSP side.

Good luck,
Mark Chambers

RE: Help!

[soar.wu]

RGVhciBNYXJrLA0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZGV0YWlsZWQgcmVwbHkuDQoNCkkgd2ls
bCBjb250aW51ZSB0byBjaGVjayBpdC4NCg0KVGhhbmsgeW91Lg0KDQpTb2FyIFd1DQoNCi0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJrIENoYW1iZXJzIFttYWlsdG86bWFya2NA
bWFpbC5jb21dDQpTZW50OiAyMDA0xOoxMNTCMjfI1SAyMDoyMA0KVG86IHNvYXIud3UNCkNjOiBs
aW51eHBwYy1lbWJlZGRlZEBvemxhYnMub3JnDQpTdWJqZWN0OiBSZTogSGVscCENCg0KDQo+IFll
cywgdGhlICdIUEknIC0gYXJlIGNvbm5lY3RlZCB0byBhIFQuSS4gRFNQLCA2NDE2IHR5cGUuDQo+
DQo+IEFib3V0IHRoZSBIUEkgcHJvYmxlbSBwcm9ncmVzcy4NCj4gbm93IHdlIGhhdmUgdGhlIGZv
bGxvd2luZyByZXNvbHZlIG1ldGhvZDoNCj4NCj4gMSwgSWYgd2UgdXNlIGEgdGVtcCB2YXJpYWJs
ZSB0byBzdG9yZSB0aGUgcmVhZCBvdXQgZGF0YSwgdGhlbiBzdG9yZSB0aGUNCmRhdGEgdG8gU0RS
QU0sIGl0IGlzIE9LLCB0aGVyZSBpcyBubyBob3AuDQo+ICAgICAgdG1wUmVhZFJzdCA9IFJFQURf
VUxfSFBJX1JFRyhVTF9IUElEQV9BRERSKTsNCj4gICAgICpwX2N1ciA9IHRtcFJlYWRSc3Q7DQo+
ICAgICAgcF9jdXIrKzsNCj4NCj4gMiwgSWYgd2UgZG9ub3QgbW9kaWZ5IHRoZSBzb3VyY2UgY29k
ZXMsIGJ1dCB3ZSB1c2UgdGhlIG9wdGltaXphdGlvbiBPMyB0bw0KY29tcGlsZSB0aGUgc291cmNl
IGNvZGVzLCBpdCBpcyBPSy4NCj4gKnBfY3VyID0gUkVBRF9VTF9IUElfUkVHKFVMX0hQSURBX0FE
RFIpOw0KPiBwX2N1cisrOw0KPg0KPiAzLCBJZiB3ZSBhZGQgYSBzeW5jIGluc3RydWN0aW9uIHRv
IHRoZSBzb3VyY2UgIGNvZGVzLCBpdCBpcyBPSy4NCj4gKnBfY3VyID0gUkVBRF9VTF9IUElfUkVH
KFVMX0hQSURBX0FERFIpOw0KPiAgICAgICAgICAgICBfX2FzbV9fKCIgIGVpZWlvOyBzeW5jIik7
DQo+IHBfY3VyKys7DQo+DQo+IDQsIElmIHdlIG1vZGlmeSB0aGUgQlNQLCB1cGRhdGUgdGhlIG1l
bW9yeSBvcGVyYXRpb24gb3B0aW9uLA0KPiBmcm9tIDoNCj4gUEhZU19NRU1fREVTQyBzeXNQaHlz
TWVtRGVzYyBbXSA9DQo+IHsNCj4gLi4uDQo+ICAgICAvKmFsbCB0aGUgb3RoZXIgc21hbGwgY2hp
cCovDQo+ICAgICB7DQo+ICAgICAodm9pZCAqKSAweDUwMDAwMDAwLA0KPiAgICAgKHZvaWQgKikg
MHg1MDAwMDAwMCwNCj4gICAgIDB4MDgwMDAwMDAsDQo+ICAgICBWTV9TVEFURV9NQVNLX1ZBTElE
IHwgVk1fU1RBVEVfTUFTS19XUklUQUJMRSB8DQpWTV9TVEFURV9NQVNLX0NBQ0hFQUJMRSwNCj4g
ICAgIFZNX1NUQVRFX1ZBTElEICAgICAgfCBWTV9TVEFURV9XUklUQUJMRSAgICAgIHwgVk1fU1RB
VEVfQ0FDSEVBQkxFX05PVA0KPiAgICAgfSwNCj4gLi4uDQo+IHRvOg0KPiBQSFlTX01FTV9ERVND
IHN5c1BoeXNNZW1EZXNjIFtdID0NCj4gew0KPiAuLi4NCj4gICAgIC8qYWxsIHRoZSBvdGhlciBz
bWFsbCBjaGlwKi8NCj4gICAgIHsNCj4gICAgICh2b2lkICopIDB4NTAwMDAwMDAsDQo+ICAgICAo
dm9pZCAqKSAweDUwMDAwMDAwLA0KPiAgICAgMHgwODAwMDAwMCwNCj4gICAgIFZNX1NUQVRFX01B
U0tfVkFMSUQgfCBWTV9TVEFURV9NQVNLX1dSSVRBQkxFIHwgVk1fU1RBVEVfTUFTS19DQUNIRUFC
TEUNCnwgVk1fU1RBVEVfTUFTS19HVUFSREVELA0KPiAgICAgVk1fU1RBVEVfVkFMSUQgICAgICB8
IFZNX1NUQVRFX1dSSVRBQkxFICAgICAgfCBWTV9TVEFURV9DQUNIRUFCTEVfTk9UDQp8IFZNX1NU
QVRFX0dVQVJERUQNCj4gICAgIH0sDQo+IC4uLg0KPg0KPiBXZSBhZGRlZCB0aGUgb3B0aW9uIFZN
X1NUQVRFX1ZNX01BU0tfR1VBUkRFRCBhbmQgVk1fU1RBVEVfR1VBUkRFRCwNCj4gc3RpbGwgdXNl
IHRoZSBvbGQgc291cmNlIGNvZGVzOg0KPiAqcF9jdXIgPSBSRUFEX1VMX0hQSV9SRUcoVUxfSFBJ
REFfQUREUik7DQo+IHBfY3VyKys7DQo+DQo+IE5vdyBXZSBmaW5kIHRoZXJlIGlzIG5vIGhvcC4g
SXQgaXMgT0sNCj4NCj4NCj4gNSwgSWYgd2UgdXNlIHRoZSBtZW1vcnkgd2hpY2ggaXMgYWxsb2Nh
dGVkIGJ5IGZ1bmN0aW9uIGNhY2hlRG1hTWFsbG9jKCksDQo+IHRoZSBob3Agc3RpbGwgZXhpc3Qs
IGJ1dCB0aGUgbnVtYmVyIG9mICBob3AgaXMgbGl0dGxlIHRoYW4gd2hlbiB3ZSB1c2UNCm1hbGxv
YygpLg0KPg0KPiBEbyB5b3UgdGVsbCBtZSB0aGUgcmVhc29uPz8NCj4NCg0Kc3lzUGh5c01lbURl
c2M/IFRoaXMgaXMgVnhXb3Jrcywgbm90IGxpbnV4LCByaWdodD8gIFdlbGwsIHRoZSBzYW1lIGdl
bmVyYWwNCnBvaW50cyBjYW4gYmUgbWFkZSwgYnV0IHRoaXMgbGlzdCBpcyBub3QgdGhlIHJpZ2h0
IG9uZSBmb3IgVnhXb3JrcyBpc3N1ZXMuDQoNCjEpIEV2ZW4gdGhvdWdoIHRoZSA4MjYwIGlzIGNh
Y2hlLWNvaGVyZW50IHlvdSBzaG91bGQgbWFrZSBzdXJlIHRoZSBNTVUgaXMNCnNldCB1cCBzbyB0
aGUgSFBJIHNwYWNlIGlzIG5vbi1jYWNoZWQuDQoyKSBJbiBDIGNvZGUgbWFrZSBzdXJlIHRoZSBI
UEkgc3BhY2UgaXMgZGVjbGFyZWQgYXMgJ3ZvbGF0aWxlJyBzbyB0aGUNCmNvbXBpbGVyIGRvZXNu
J3Qgb3B0aW1pemUgb3V0IHJlZmVyZW5jZXMgdG8gdGhlIGFkZHJlc3MuDQozKSBSZW1lbWJlciB0
aGF0IHRoZSBIUEkgaW50ZXJmYWNlIG9uIHRoZSBEU1AgaXMgRE1BIGRyaXZlbiBhbmQgZ29lcyB0
aHJvdWdoDQphIEZJRk8sIHNvIHRoYXQgd3JpdGVzIHRvIERTUCBtZW1vcnkgaGF2ZSBhIGRlbGF5
IGJlZm9yZSB0aGV5IGFjdHVhbGx5DQphcHBlYXIgaW4gRFNQIG1lbW9yeS4gIEFuZCBkb24ndCBm
b3JnZXQgdG8gbG9vayBhdCBjYWNoZSBpc3N1ZXMgb24gdGhlIERTUA0Kc2lkZS4gIFlvdXIgcHJv
YmxlbSBtYXkgYWN0dWFsbHkgYmUgb24gdGhlIERTUCBzaWRlIGFuZCB5b3VyIHZhcmlvdXMgZml4
ZXMNCmFyZSBqdXN0IGludHJvZHVjaW5nIGVub3VnaCBkZWxheSBmb3IgdGhpbmdzIHRvIGNvbXBs
ZXRlIG9uIHRoZSBEU1Agc2lkZS4NCg0KR29vZCBsdWNrLA0KTWFyayBDaGFtYmVycw0KDQo=

Help!

[btjiang]

Hello, 
     I do not understand some things about netfilter.There are two hash table in NAT(bysource and byipsproto).What are they used for?It's just for fast check? Please help me! 
                                 Lucky! 
                                               

charlie

Help!

[btjiang]

Hello,
     I do not understand some things about netfilter.There are two hash table in NAT(bysource and byipsproto).What are they used for?It's just for fast check? Please help me!
                                 Lucky!
                                              
charlie

HELP!

[sood101]

Dear Friend.
As you read this, I don't want you to feel sorry for me, because, I believe everyone will die someday. My name is Alwani M. Sood, a merchant in Dubai, in the U.A.E.I have been diagnosed with Esophageal cancer .It has defiled all forms of medical treatment, and right now I have only about a few months to live, according to medical experts. 

I have not particularly lived my life so well, as I never really cared for anyone(not even myself)but my business. Though I am very rich, I was never generous, I was always hostile to people and only focused on my business as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world.
I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that God has called me, I have willed and given most of my property and assets to my immediate and extended family members as well as a few close friends. 
I want God to be merciful to me and accept my soul so, I have decided to give alms to charity organizations, as I want this to be one of the last good deeds I do on earth. So far, I have distributed money to some charity organizations in the U.A.E, Algeria and Malaysia. Now that my health has deteriorated so badly, I cannot do this myself anymore. I once asked members of my family to close one of my accounts and distribute the money which I have there to charity organization in Bulgaria and Pakistan, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. 
The last of my money which no one knows of is the huge cash deposit of twenty two million dollars $22,000,000,that I have with finance/Security Company abroad. I will want you to help me collect this deposit and dispatched it to charity organizations. 
I have set aside 20% for you for your time and patience.please send a reply through this email address with your full contact information for more private and confidential communication.Please reply to my private email address:(alwani101sood@netscape.net)
God be with you.

Alwani M. Sood.



----------------
Powered by telstra.com
                                                                      

HELP!

[alsood]

Dear Friend.
As you read this, I don't want you to feel sorry for me, because, I believe everyone will die someday. My name is Alwani M. Sood, a merchant in Dubai, in the U.A.E.I have been diagnosed with Esophageal cancer .It has defiled all forms of medical treatment, and right now I have only about a few months to live, according to medical experts. 

I have not particularly lived my life so well, as I never really cared for anyone(not even myself)but my business. Though I am very rich, I was never generous, I was always hostile to people and only focused on my business as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world.
I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that God has called me, I have willed and given most of my property and assets to my immediate and extended family members as well as a few close friends. 
I want God to be merciful to me and accept my soul so, I have decided to give alms to charity organizations, as I want this to be one of the last good deeds I do on earth. So far, I have distributed money to some charity organizations in the U.A.E, Algeria and Malaysia. Now that my health has deteriorated so badly, I cannot do this myself anymore. I once asked members of my family to close one of my accounts and distribute the money which I have there to charity organization in Bulgaria and Pakistan, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. 
The last of my money which no one knows of is the huge cash deposit of twenty two million dollars $22,000,000,that I have with finance/Security Company abroad. I will want you to help me collect this deposit and dispatched it to charity organizations. 
I have set aside 20% for you for your time and patience.please send a reply through this email address with your full contact information for more private and confidential communication.Please reply to my private email address:(alwanisoodpvt@netscape.net)
God be with you.

Alwani M. Sood.






----------------
Powered by telstra.com
                                                                      

help!!

[Tuyo Board Unilago]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

Hi, This is probably very basic to all of you guys, but i would apreciate a helping hand.

I have a linux red hat 9.2, 2.4 kernel machine with a cable modem signal with a DHCP ip adress from the cable company

I´m tring to "PROXY" all services to internet : telnet, Kazaa, httpd, etc...

But the more i try, the father my goal seems.

I been reading all the how to´s but no luck.

Any help. ANY. Will be apreciated.

Thanks

Tuyo Isaza



[-- Attachment #2: Type: text/html, Size: 1566 bytes --]

HELP!

[Karl F. Larsen]

	How do I turn off this list?

-- 
                      
               - Karl Larsen k5di Las Cruces,NM Az ScQRPions -



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: HELP!

[Bret Comstock Waldow]

Every mail message that originates from this list has the administrative 
info and addreses added to the bottom.  You will find your answer there. 
 The links work fine on my copy of your message.

If you've tried this, and it doesn't seem to have worked, you should say 
that in your message - I doubt anyone here reads minds.

I also will suggest you use mail Subject lines that actually communicate 
something about what's in the message.  One of the tricks crackers and 
virus programs use is attention grabbing subject lines, to get people to 
act without thinking.  People who do think are likely to ignore 
simplistic headers from people they don't know - that's one of the 
recommended, published things to watch out for.

The more intelligence you put into your communications, the more respect 
and response you'll get from the people you're communicating with.

If you have trouble with the instructions appended by the list to the 
end of the message about how to deal with the list, please tell us what 
you did, and what didn't work, so people can tell what might help.  What 
have you already tried?  Do the links at the bottom of the message not 
work on your system?  Are they missing?

Cheers,
Bret


Karl F. Larsen wrote:

> 
>
>	How do I turn off this list?
>




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

HELP!!!!!!!!

[Dinu M.C]

Hi!
I am a new user of MDK linux.....and I need run a MS-DOS program;
I try dosemu from the install. CD (ver. 3.9.xxx) and everything work just fine.....
but my program NOT.
That is the error message I recive:


"C:\WINFARM>winfarm.exe

Phar Lap err 35: The 386 chip is currently executing
in virtual 8086 mode under the control of another program.  You must turn
off this other program in order to use 386|DOS-Extender to run in
protected mode."



LITTLE HELP, PLEASE!!!!!


my addresses:
		 dinu_l@personal.ro 
			or
		dinu_l@hotmail.com
			or
		florea_luciana@yahoo.com


______________________________________________________________________
Do you want a free e-mail for life ? Get it at http://www.personal.ro/

Help!!!

[Bharat (Hotmail Mithibaiguy)]

[-- Attachment #1: Type: text/plain, Size: 428 bytes --]

Hi,

Your help on iptables for blocking msn was pretty useful but the way u mentioned that u will be writing additional scripts to to make the rules permanent after linux is booted. 

I have successfully blocked msn but the rule just stays till i reboot the box or restart the iptable services.

Would be really obliged if u could help me on this to help me make the rules permanent



Thanks in advance

Bharat 


[-- Attachment #2: Type: text/html, Size: 776 bytes --]

help!

[weiwu]

I begnan to learn how to write a block moudle,but I have some questions.
1.
how to write  functions of "fdisk mount " ?
2.
we can find a "drive moudle " everywhere,but I can not find a "user moudle" reference.
I need a reference moudle for Intel flash.
who can share with me?
Thanks for any replies.

            weiwu
            weiwu@isdn.iscas.ac.cn

help!

[rou]

With all my respect,   
This is new for me and I wouldn't like to disturb anybody.

Since some months ago I'm looking for work and it's beeing dificult 
to find a good place and position. I have experience in communications, 
hardware & software, protocols, security, programming, cryptogaphy   
and many other things.

I need a work, please, help!.

Help!

[Jeremy Welling]

I've got a G3 minitower.  I can't get it linux to acknowledge the ultra
scsi drive.  I tried to bypass the builtin scsi by plugging it into the
pci scsi card.  No help.  I've also tried kernels 2.2.1 thru 2.2.7.  I
started by partitioning the internal drive with the correct partitions.
When boot linux through bootX, I go into the redhat installer and it
can't find the disk.  I drop out to the redhat messages and it says
"/proc/scsi/scsi: Attached devices: none".  The kernel messages note
detecting scsi0 :  MESH  scsi : 1 host.  and no other controllers.  If
anyone has any input, it would be greatly appreciated.

Thanks!
Jeremy Welling

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]