|
|
|
|
|
|
| Author |
Message |
left_coast
*nix forums addict
Joined: 23 May 2006
Posts: 62
|
 Posted: Thu Jul 20, 2006 10:50 pm Post subject:
Re: Test of Posting to Newsgroup
|
|
|
Chris F.A. Johnson wrote:
| Quote: | On 2006-07-20, test dirt wrote:
Michael Black wrote:
Note the bozo posted to
alt.linux.suse
alt.os.linux.dial-up
alt.os.linux.suse
at.linux
comp.os.linux.hardware
comp.os.linux.setup
so not only did he not bother with a test newsgroup, but he couldn't
even limit it to one newsgroup.
And you reply-post to half of those.
Makes you look like a half-assed bozo.
Which is, at most, half as bad as the OP and his defenders.
|
That is only a matter of degree, you are still guilty of the same as "the OP
and his defenders".
--
Still waiting for a rational answer from Bittwister to this:
<nfqlo3-qds.ln1@alta.sierrandays.org>. |
|
| Back to top |
|
 |
Bit Twister
*nix forums Guru
Joined: 19 Feb 2005
Posts: 1546
|
| Posted: Thu Jul 20, 2006 1:04 am Post subject:
Re: Test of Posting to Newsgroup
|
|
|
On Wed, 19 Jul 2006 20:02:11 -0500, Clois Beckwith wrote:
| Quote: | Running a test of writing to Newsgroups Specific.
|
Welcome to the group.
Since the post showed up here, the test failed. 
Do you know about the 400+ test groups on Usenet.
Some interesting information may be found in
http://livinginternet.com/u/uu_test.htm
Please use something like alt.test or misc.test .
For binary test use something like alt.binaries.test
Please, before you post again, read
http://tgos.org/newbie/index2.html
http://www.catb.org/~esr/faqs/smart-questions.html |
|
| Back to top |
|
|
Henrik Carlqvist
*nix forums Guru
Joined: 19 Feb 2005
Posts: 648
|
| Posted: Wed Jul 19, 2006 5:24 pm Post subject:
Re: problems mounting external drive
|
|
|
"onetitfemme" <onetitfemme2005@yahoo.com> wrote:
| Quote: | I am trying to mount my external drive. I think it had a FAT32
partition of 80Gb (the whole drive), but I am not able to.
|
Did that partition contain any important data?
| Quote: | sh-3.1# fdisk -l /dev/sda
Disk /dev/sda: 80.0 GB, 80037281792 bytes
255 heads, 63 sectors/track, 9730 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /dev/sda doesn't contain a valid partition table
|
For some reason the partition table is lost. Maybe all data has also been
lost for the same reason. If the drive didn't contain anything important
the quick and easy fix would probably be to run fdisk, add a partition
format that partition and then mount it.
If you want to try to save some data it would be safest if you started
with an image of your disk. This way you can experiment with the image
without risking damaging the disk contents even more:
dd if=/dev/sda of=/var/tmp/sda.img
regards Henrik
--
The address in the header is only to prevent spam. My real address is:
hc8(at)uthyres.com Examples of addresses which go to spammers:
root@variousus.net root@localhost |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
*nix forums beginner
Joined: 15 Apr 2005
Posts: 20
|
| Posted: Mon Jul 10, 2006 10:01 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
mikpe@harpo.csd.uu.se (Mikael Pettersson) writes:
| Quote: | In article <7zwtalop60.fsf@app-2.diku.dk>,
Torben Ęgidius Mogensen <torbenm@app-2.diku.dk> wrote:
Having a "register" that takes on special values (0, -1, PC, ...)
depending on the instruction seems more useful than the constant-zero
register you find on MIPS and others.
I disagree. PowerPC has this "feature" (r0 is either a constant
0 or a normal GPR depending on the instruction) and it just
causes special cases and confusion in a compiler backend.
|
I think your problem is related to the fact that it _can_ be used as a
GPR, so the register allocator tries to use it (when its use doen't
conflict with the restrictions). If it can't be used as a GPR, you
just never allocate it, but only use it to encode special variants of
other instructions. I.e., it is only in the instruction selection
process that you need to worry about this register.
I would probably do the same in a compiler for the PPC -- with 32
registers, you can afford to have one that the register allocator
doesn't touch, but only use in prologues and epilogues of functions or
as a temporary register when encoding one intermediate-language
instruction a several PPC instructions (and, hence, know if these
instructions use it as 0 or not).
Torben |
|
| Back to top |
|
|
Mikael Pettersson
*nix forums beginner
Joined: 29 Aug 2005
Posts: 16
|
| Posted: Mon Jul 10, 2006 9:18 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
In article <7zwtalop60.fsf@app-2.diku.dk>,
Torben Ęgidius Mogensen <torbenm@app-2.diku.dk> wrote:
| Quote: | Having a "register" that takes on special values (0, -1, PC, ...)
depending on the instruction seems more useful than the constant-zero
register you find on MIPS and others.
|
I disagree. PowerPC has this "feature" (r0 is either a constant
0 or a normal GPR depending on the instruction) and it just
causes special cases and confusion in a compiler backend.
--
Mikael Pettersson (mikpe@csd.uu.se)
Computing Science Department, Uppsala University |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
*nix forums beginner
Joined: 15 Apr 2005
Posts: 20
|
| Posted: Mon Jul 10, 2006 8:11 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
"Wilco Dijkstra" <Wilco_dot_Dijkstra@ntlworld.com> writes:
| Quote: | ""Torben Ęgidius Mogensen"" <torbenm@app-4.diku.dk> wrote in message
news:7zd5ck4b3p.fsf@app-4.diku.dk...
What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC.
Thumb-2 has effectively done this. Most uses of the PC are forbidden,
and the encoding is used for other purposes. MUL is now an encoding
of MLA with R15 as the accumulator (which reads as zero) rather than
using another opcode. The MOV/MVN/CMP/CMN instructions are
special cases of 3-operand instructions using R15 as a register
containing all ones or zeroes. There is a new addressing mode for
PC-relative loads, and all effective addresses can now be generated
using a single add instruction.
|
Interesting. Thanks for the info. I must admit that I haven't
studied Thumb2 in any detail yet, but I plan to do so soon.
Having a "register" that takes on special values (0, -1, PC, ...)
depending on the instruction seems more useful than the constant-zero
register you find on MIPS and others.
Torben |
|
| Back to top |
|
|
Wilco Dijkstra
*nix forums beginner
Joined: 11 Jan 2006
Posts: 2
|
| Posted: Sun Jul 09, 2006 4:53 pm Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
""Torben Ęgidius Mogensen"" <torbenm@app-4.diku.dk> wrote in message
news:7zd5ck4b3p.fsf@app-4.diku.dk...
| Quote: | John Cartmell <john@cartmell.demon.co.uk> writes:
BTW The discussions about 26 bit and 32 bit architecture won't make sense
from
outside. Both architectures are 32 bit but the older one uses 6 of those
bits
in a particular way. The latest chips won't allow that (even though the
old
form was better) so there is need to update older software or apply a
form of
emulation. Properly updated/new software will run on new and older
hardware.
I don't agree that the "old" way was better.
|
Indeed. There is no benefit from having a BL preserve the flags. The only
feature I miss in assembly programming is the ability to write 4 random
bits in the NZCV flags in a single instruction and then conditionally
execute
instructions based on the flags. This is useful for fast bitblitting.
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC.
|
Thumb-2 has effectively done this. Most uses of the PC are forbidden,
and the encoding is used for other purposes. MUL is now an encoding
of MLA with R15 as the accumulator (which reads as zero) rather than
using another opcode. The MOV/MVN/CMP/CMN instructions are
special cases of 3-operand instructions using R15 as a register
containing all ones or zeroes. There is a new addressing mode for
PC-relative loads, and all effective addresses can now be generated
using a single add instruction.
| Quote: | It would
require a few extra instructions for saving and restoring the PC as
well as indirect jumps (such as function call returns) and
position-relative loads, but it would remove a number of special cases
in instructions for the case where one of the registers is the PC, and
it would leave one more register available for general use. It would
probably also simplify the pipeline.
|
LDR pc,[...] and POP {...,pc} were kept since these are very common
return instructions. However you're right in that the first can be replaced
by the latter in most cases and special instructions could be introduced
to handle the few cases where the PC is currently needed. Thumb-2
introduced TBB for switch statements so you don't need the odd
ADD pc,pc,rx,LSL #2 anymore. There are few uses of the PC in
compiled code nowadays and that is how it should be.
I agree that having the PC and SP as general purpose registers
was a really bad idea. They introduce too many special cases that
need checking in both hardware and software (compilers/assemblers),
and that while almost all of those instructions are totally useless...
I don't think the pipeline is affected much, it is mainly decode and
validation. One of the good things in Thumb-1 is that it added special
instructions to deal with PC or SP (PUSH/POP/ADR etc). Thumb-2
continues this and made just about all odd uses of PC/SP illegal.
Wilco |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
*nix forums beginner
Joined: 15 Apr 2005
Posts: 20
|
| Posted: Fri Jul 07, 2006 9:50 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
Peter Naulls <peter@chocky.org> writes:
| Quote: | In message <7zac7n9kl7.fsf@app-4.diku.dk
torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
druck <news@druck.freeuk.com> writes:
On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
Its actually only 64MB of code space (2^26).
These are 2^26 words of four bytes each, so 256MB.
Not quite. Bits 0-1 = processor mode, Bits 2-25 = PC, Bits 26-32 =
flags. There are 24 bits of four byte words, or 26-bit addresseable.
|
Right. I forgot the interrupt flags, so I counted only the four
arithmetic flags.
Torben |
|
| Back to top |
|
|
druck
*nix forums beginner
Joined: 19 May 2005
Posts: 5
|
| Posted: Thu Jul 06, 2006 5:00 pm Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
On 6 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
| Quote: | druck <news@druck.freeuk.com> writes:
On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
it did limit the number of modes to 4 and limited the PC range to 256MB.
Its actually only 64MB of code space (2^26).
These are 2^26 words of four bytes each, so 256MB.
|
No, its 2^26 bytes as the bottom two bits are the mode flags, and the top 6
bits are the PSR flags, hence actually only 2^24 WORDs of PC range.
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC.
Madness! For one you lose all PC relative memory accesses, and have to
introduce a whole new set of instructions. The same for calculated
branches.
The minimal requirement would be instructions for transferring the PC
to a normal register and vice versa (like was added for transferring
PSW). This would at most add one extra instruction to the cases where
the current ISA uses the PC in instructions,
|
In otherwords a huge penalty on the most common data addressing mode, severly
impacting ipc.
| Quote: | but often this is not required (MOV PC, r14 comes to mind as a case that
would be translated into only one instruction).
|
It is only one instruction?
| Quote: | The main cases where translation isn't 1:1 are loading the PC from memory
(for example, an LDM that restores callee-saves registers and the returns
from the call) and for constant-pools in the code. For the LDM, you can
use the "^" bit to indicate that a load to the link register should be to
the PC instead. For position-relative loads, the best is probably to add a
new instruction. Position-relative stores are not very common, so only
loading would deserve a new instruction.
|
As I said; madness.
| Quote: | But the entire point of using a GP register for the PC is it not then a
special case but handled in exactly the same way by the processor as any
other register, reducing complxity and power consumption. Its only a
'special case' in the mind of the programmer, and I suggest an immediate
upgrade.
On the contrary, most programmers regard R15 as being "just another
register that just happens to hold the address of the next instruction",
but the hardware nearly always special-cases instructions that use the PC.
In the original ARM, the PC could be 8 or 12 bytes ahead of the current
instruction depending on whether the instruction is single-cycle or
multiple-cycle. This was changed (I don't recall exactly when, it may have
been ARM 7 or ARM  so the PC would always (when read as R15) be 8 bytes
ahead, no matter how long the pipeline is. But this has required two
out-of-sync copies of the PC: one for use as R15 and another for fetching
instructions.
|
They aren't out of sync, they maintain a precise relationship of 8 bytes
apart.
| Quote: | Additionally, several instructions modify their semantics when R15 is used
as source or destination. So allowing the PC to be used in all
instructions becomes a burden for the implementation.
|
Theres far less specical cases than you think, and the current system is far
simpiler and more othorganal than introducing the frankly horrible bodges
which you have proposed above.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/ |
|
| Back to top |
|
|
Peter Naulls
*nix forums beginner
Joined: 06 Jul 2006
Posts: 1
|
| Posted: Thu Jul 06, 2006 3:01 pm Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
In message <7zac7n9kl7.fsf@app-4.diku.dk>
torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
| Quote: | druck <news@druck.freeuk.com> writes:
On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
Its actually only 64MB of code space (2^26).
These are 2^26 words of four bytes each, so 256MB.
|
Not quite. Bits 0-1 = processor mode, Bits 2-25 = PC, Bits 26-32 =
flags. There are 24 bits of four byte words, or 26-bit addresseable.
--
Peter Naulls - peter@chocky.org | http://www.chocky.org/
----------------------------------------------------------------------------
RISC OS Community Wiki - add your own content | http://www.riscos.info/ |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
*nix forums beginner
Joined: 15 Apr 2005
Posts: 20
|
| Posted: Thu Jul 06, 2006 8:57 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
druck <news@druck.freeuk.com> writes:
| Quote: | On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
John Cartmell <john@cartmell.demon.co.uk> writes:
BTW The discussions about 26 bit and 32 bit architecture won't make sense
from outside. Both architectures are 32 bit but the older one uses 6 of
those bits in a particular way. The latest chips won't allow that (even
though the old form was better) so there is need to update older software
or apply a form of emulation. Properly updated/new software will run on
new and older hardware.
I don't agree that the "old" way was better. While having the PSW use the
four upper bits of the PC and using the two low bits for processor mode
meant you could need only one save to save both PC and status word,
It was very clean, but because of this flag preserving became the defaco
standard for all procedure calls, and as we now know from performing 32bit
ports, its unnecessary in the vast majority of cases. In the few cases where
it is required, there is very little penalty from introducing callee branch
overs.
it did limit the number of modes to 4 and limited the PC range to 256MB.
While 256MB was enough in the 90s, it is a limitation today (though you can
argue that most of the RAM used on modern machines is for data, not
programs).
Its actually only 64MB of code space (2^26).
|
These are 2^26 words of four bytes each, so 256MB.
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered register
at the same time they moved the PSW out of the PC. It would require a few
extra instructions for saving and restoring the PC as well as indirect
jumps (such as function call returns) and position-relative loads,
Madness! For one you lose all PC relative memory accesses, and have to
introduce a whole new set of instructions. The same for calculated branches.
|
The minimal requirement would be instructions for transferring the PC
to a normal register and vice versa (like was added for transferring
PSW). This would at most add one extra instruction to the cases where
the current ISA uses the PC in instructions, but often this is not
required (MOV PC, r14 comes to mind as a case that would be translated
into only one instruction). The main cases where translation isn't
1:1 are loading the PC from memory (for example, an LDM that restores
callee-saves registers and the returns from the call) and for
constant-pools in the code. For the LDM, you can use the "^" bit to
indicate that a load to the link register should be to the PC instead.
For position-relative loads, the best is probably to add a new
instruction. Position-relative stores are not very common, so only
loading would deserve a new instruction.
| Quote: | but it would remove a number of special cases in instructions for
the case where one of the registers is the PC, and it would leave
one more register available for general use. It would probably
also simplify the pipeline.
But the entire point of using a GP register for the PC is it not then a
special case but handled in exactly the same way by the processor as any
other register, reducing complxity and power consumption. Its only a 'special
case' in the mind of the programmer, and I suggest an immediate upgrade.
|
On the contrary, most programmers regard R15 as being "just another
register that just happens to hold the address of the next
instruction", but the hardware nearly always special-cases
instructions that use the PC. In the original ARM, the PC could be 8
or 12 bytes ahead of the current instruction depending on whether the
instruction is single-cycle or multiple-cycle. This was changed (I
don't recall exactly when, it may have been ARM 7 or ARM so the PC
would always (when read as R15) be 8 bytes ahead, no matter how long
the pipeline is. But this has required two out-of-sync copies of the
PC: one for use as R15 and another for fetching instructions.
Additionally, several instructions modify their semantics when R15 is
used as source or destination. So allowing the PC to be used in all
instructions becomes a burden for the implementation.
Torben |
|
| Back to top |
|
|
druck
*nix forums beginner
Joined: 19 May 2005
Posts: 5
|
| Posted: Wed Jul 05, 2006 10:28 pm Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
On 5 Jul 2006 torbenm@app-4.diku.dk (Torben Ęgidius Mogensen) wrote:
| Quote: | John Cartmell <john@cartmell.demon.co.uk> writes:
BTW The discussions about 26 bit and 32 bit architecture won't make sense
from outside. Both architectures are 32 bit but the older one uses 6 of
those bits in a particular way. The latest chips won't allow that (even
though the old form was better) so there is need to update older software
or apply a form of emulation. Properly updated/new software will run on
new and older hardware.
I don't agree that the "old" way was better. While having the PSW use the
four upper bits of the PC and using the two low bits for processor mode
meant you could need only one save to save both PC and status word,
|
It was very clean, but because of this flag preserving became the defaco
standard for all procedure calls, and as we now know from performing 32bit
ports, its unnecessary in the vast majority of cases. In the few cases where
it is required, there is very little penalty from introducing callee branch
overs.
| Quote: | it did limit the number of modes to 4 and limited the PC range to 256MB.
While 256MB was enough in the 90s, it is a limitation today (though you can
argue that most of the RAM used on modern machines is for data, not
programs).
|
Its actually only 64MB of code space (2^26).
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered register
at the same time they moved the PSW out of the PC. It would require a few
extra instructions for saving and restoring the PC as well as indirect
jumps (such as function call returns) and position-relative loads,
|
Madness! For one you lose all PC relative memory accesses, and have to
introduce a whole new set of instructions. The same for calculated branches.
| Quote: | but it would remove a number of special cases in instructions for the case
where one of the registers is the PC, and it would leave one more register
available for general use. It would probably also simplify the pipeline.
|
But the entire point of using a GP register for the PC is it not then a
special case but handled in exactly the same way by the processor as any
other register, reducing complxity and power consumption. Its only a 'special
case' in the mind of the programmer, and I suggest an immediate upgrade.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/ |
|
| Back to top |
|
|
Mikael Pettersson
*nix forums beginner
Joined: 29 Aug 2005
Posts: 16
|
| Posted: Wed Jul 05, 2006 11:33 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
In article <7zd5ck4b3p.fsf@app-4.diku.dk>,
Torben Ęgidius Mogensen <torbenm@app-4.diku.dk> wrote:
| Quote: | What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC. It would
require a few extra instructions for saving and restoring the PC as
well as indirect jumps (such as function call returns) and
position-relative loads, but it would remove a number of special cases
in instructions for the case where one of the registers is the PC, and
it would leave one more register available for general use. It would
probably also simplify the pipeline.
|
Speaking in my role as a compiler & runtime system hacker, I think
that having the PC as a GPR is one of the nicest features of ARM!
Admittedly, the most important use of it is for PC-relative addressing,
so if Yet Another Silly Addressing Mode was invented for that
(ARM has way too many addressing modes, but it's instruction encoding
is crap so it needs them) plus new instructions for returns and
indirect calls, then having PC as a hidden register would be OK.
The incremental gain of going from 15 to 16 GPRs is rather small,
so I don't buy that argument. Improved pipeline, maybe, but I'm
no chip designer.
Straight-line code performance isn't everything. Constructing immediates,
function call/ret sequences, and linkage between separately compiled and/or
loaded modules are also very important, and PC-as-GPR does help those cases.
--
Mikael Pettersson (mikpe@csd.uu.se)
Computing Science Department, Uppsala University |
|
| Back to top |
|
|
Torben Ęgidius Mogensen
*nix forums beginner
Joined: 15 Apr 2005
Posts: 20
|
| Posted: Wed Jul 05, 2006 10:09 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
John Cartmell <john@cartmell.demon.co.uk> writes:
| Quote: | BTW The discussions about 26 bit and 32 bit architecture won't make sense from
outside. Both architectures are 32 bit but the older one uses 6 of those bits
in a particular way. The latest chips won't allow that (even though the old
form was better) so there is need to update older software or apply a form of
emulation. Properly updated/new software will run on new and older hardware.
|
I don't agree that the "old" way was better. While having the PSW use
the four upper bits of the PC and using the two low bits for processor
mode meant you could need only one save to save both PC and status
word, it did limit the number of modes to 4 and limited the PC range
to 256MB. While 256MB was enough in the 90s, it is a limitation today
(though you can argue that most of the RAM used on modern machines is
for data, not programs).
What I regret is that ARM didn't also move the PC to an unnumbered
register at the same time they moved the PSW out of the PC. It would
require a few extra instructions for saving and restoring the PC as
well as indirect jumps (such as function call returns) and
position-relative loads, but it would remove a number of special cases
in instructions for the case where one of the registers is the PC, and
it would leave one more register available for general use. It would
probably also simplify the pipeline.
Torben |
|
| Back to top |
|
|
Paul Gotch
*nix forums beginner
Joined: 10 Jan 2006
Posts: 3
|
| Posted: Wed Jul 05, 2006 8:31 am Post subject:
Re: Are ARM based 'boxes' available to buy ?
|
|
|
In comp.sys.arm news <news@absamail.co.za> wrote:
| Quote: | [Oberon S3] which "has an ARM port". But I'm not sure that all
models are compatible. I'm confused at reading "26 bit emulator" ?
|
The 26 bit architecture was deprecated years ago and was completely removed
in ARMv6. You therefore need a software emulator to execute 26 bit code on a
modern ARM.
-p
--
Gotch, n. A corpulent beer-jug of some strong ware.
Gotch, v. To surprise with a remark that negates or usurps a remark
that has just been made.
-------------------------------------------------------------------- |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Wed Dec 03, 2008 8:50 pm | All times are GMT
|
|
Loan | Electricity Suppliers | Loans | Debt Help | Mortgages
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
hardware
