| View previous topic :: View next topic |
| Author |
Message |
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3174
Location: Paris
|
 Posted: Thu Apr 28, 2005 5:56 am Post subject: |
 |
|
| qnx wrote: |
After doing the test with 3Gb tarball, I even backed up my 40GB of "important data", and then checked (just basicly, by looking at the number of files, file sizes, etc), seems OK. Is there any other way of checking? I can't md5 a directory, can I? |
Well I tought using par2cmdline tools (par2create and par2verify) too, which can work on mutliple files and is very fast (without creating repair blocks, just the small error detection file).
| qnx wrote: |
The reason I did this with Reiser4 was to.. well, don't know how to put it. I just thought that "if it completes on reiser4 without any problems, then it *must* work with other, more stable FS as well"  .
|
Totaly agree 
| qnx wrote: |
If you give me a short script template (I've never been good at BASH) then I can try coping a whole dir a couple of times, just don't want to sit and do it manually 50 times
|
Errr, me neither, but a simple "for" would do it:
| Code: | #!/bin/sh
for i in `seq 1 50`
do
your command list
done |
-> Krischi:
errr, I don't know for Tyan, but SIL3114 isn't reported to be a problem for libata, just 3112 (and so I think it's unfair concerned by the "fix", it could be a simple chip detection problem, see early posts in the thread). No mention of "SIL3114 bugfix" in Sil own driver though. |
|
| Back to top |
|
 |
Krischi
n00b
Joined: 07 Feb 2004
Posts: 16
Location: Washington DC
|
| Posted: Fri Apr 29, 2005 1:54 am Post subject: |
|
|
| Quote: |
-> Krischi:
errr, I don't know for Tyan, but SIL3114 isn't reported to be a problem for libata, just 3112 (and so I think it's unfair concerned by the "fix", it could be a simple chip detection problem, see early posts in the thread). No mention of "SIL3114 bugfix" in Sil own driver though. |
This page seems to indicate that it is both a 3112 and 3114 problem. Furthermore, why would Tyan report about Linux compatibility problems on their BIOS support page, if there were not something? Right now, no one seems to know for sure which combinations exactly are affected, so some data points are a good thing. Also, if you search on Google, you will turn up other hits for BIOS updates, including, I think, the 3112. |
|
| Back to top |
|
|
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3174
Location: Paris
|
| Posted: Fri Apr 29, 2005 5:37 am Post subject: |
|
|
What I tried to explain, is that what you are talking about is another problem that what is discussed here. (See the topic: 3112, not 3114). And according to what I've read on many sites, a BIOS update for 3112 won't fix the problem I'm talking about., it seems to be a revision matter: see Sil documentation. Moreover, if Tyan sais your 3114 is solved with actual BIOS releases, well, you lucky
Conclusion: we are talking here about a 3112 specific problem that is not solved by BIOS update (thanks correcting me if you can prove the opposite). |
|
| Back to top |
|
|
I.C.Wiener
Tux's lil' helper
Joined: 25 Jul 2004
Posts: 115
Location: Furtwangen (Germany)
|
| Posted: Thu May 05, 2005 9:26 pm Post subject: |
|
|
| El_Goretto wrote: | | Conclusion: we are talking here about a 3112 specific problem that is not solved by BIOS update (thanks correcting me if you can prove the opposite). |
How can you be sure? Actually Silicon Image released a bios-update for the 3112 that fixes some sort of data-corruption - might be exactly what we're looking for.
However so far I haven't seen anyone who is really affected. And as long as there is no test to verify wether one is affected or not, we won't make any progress here. I guess there won't be any errors in syslog and not every file gets corrupted, so there's no way to be sure.
Perhaps someone could generate a file (and md5sum) that gets corrupted when being copied around on affected systems. That would make testing of bios/firmware revisions easy. |
|
| Back to top |
|
|
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3174
Location: Paris
|
| Posted: Sun May 08, 2005 7:02 pm Post subject: |
|
|
| I.C.Wiener wrote: | | El_Goretto wrote: | | Conclusion: we are talking here about a 3112 specific problem that is not solved by BIOS update (thanks correcting me if you can prove the opposite). |
How can you be sure? Actually Silicon Image released a bios-update for the 3112 that fixes some sort of data-corruption - might be exactly what we're looking for. |
Maybe. I just read the Sil driver Changelog, and there is no mention of BIOS version in it. Only Chipset Revision (which implies a minimal BIOS version, I agree).
| I.C.Wiener wrote: | | However so far I haven't seen anyone who is really affected. And as long as there is no test to verify wether one is affected or not, we won't make any progress here. I guess there won't be any errors in syslog and not every file gets corrupted, so there's no way to be sure. |
Right.
| I.C.Wiener wrote: | | Perhaps someone could generate a file (and md5sum) that gets corrupted when being copied around on affected systems. That would make testing of bios/firmware revisions easy. |
qnx is excactly testing his system that way (see below), but for me, as long as I haven't sufficient space on another drive to move my data, testing my BIOS/Seagate firmware/3112 revision configuration isn't possible. |
|
| Back to top |
|
|
qnx
l33t
Joined: 25 Jun 2002
Posts: 638
Location: Göteborg, Sweden
|
| Posted: Mon May 09, 2005 1:41 pm Post subject: |
|
|
| El_Goretto wrote: |
| I.C.Wiener wrote: | | Perhaps someone could generate a file (and md5sum) that gets corrupted when being copied around on affected systems. That would make testing of bios/firmware revisions easy. |
qnx is excactly testing his system that way (see below), but for me, as long as I haven't sufficient space on another drive to move my data, testing my BIOS/Seagate firmware/3112 revision configuration isn't possible. |
What I think I.C.Wiener is talking about is genereting a file that gets corrupted *for sure* when copied on affected combinations of drive/chipset. Something that could be used for testing, a file that is designed to *get* corrupted. I have no idea how such a file should look but there are surely others with better insight into this technical issue who might know how such a file should look like. But, on the other hand: if they'd have known how to make a generic testing file, why haven't they done it so far? Maybe impossible..?
However, as El_Goretto says, I've copied around a couple of files a couple of times after upgrading my BIOS and having modified my kernel. Take a look above in this thread.
_________________
Registred Linux user #191143!
Abit NF7-S rev. 2.00 (BIOS v. 2.7)
AMD AthlonXP 2500+ (Barton)
PATA Seagate ST3120022A
SATA Seagate ST3200822AS & Silicon Image 3112 chipset
Gentoo Linux |
|
| Back to top |
|
|
qnx
l33t
Joined: 25 Jun 2002
Posts: 638
Location: Göteborg, Sweden
|
| Posted: Wed May 11, 2005 10:10 pm Post subject: |
|
|
Hi everybody,
have anybody tried the mod15write workaround by TeJun Heo yet? I did today and it looks amazing! Check out if affected by this "dog slow" Seagate SATA disks. Also take a look at the two posts of me over here where I wrote something more about my experience.
Cheers!
_________________
Registred Linux user #191143!
Abit NF7-S rev. 2.00 (BIOS v. 2.7)
AMD AthlonXP 2500+ (Barton)
PATA Seagate ST3120022A
SATA Seagate ST3200822AS & Silicon Image 3112 chipset
Gentoo Linux |
|
| Back to top |
|
|
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3174
Location: Paris
|
| Posted: Thu May 12, 2005 5:52 am Post subject: |
|
|
Cool.
Is it the "new fix" that is supposed to be in 0.9 SATA driver or a new one? |
|
| Back to top |
|
|
qnx
l33t
Joined: 25 Jun 2002
Posts: 638
Location: Göteborg, Sweden
|
| Posted: Thu May 12, 2005 8:47 am Post subject: |
|
|
I have had sata_sil 0.9 all the time I was writing in this thread since I was using 2.6.12-rc2-love1 than and rc4-love1 now. No "new fix" in there however, had to patch myself as I said. Try out you too!
_________________
Registred Linux user #191143!
Abit NF7-S rev. 2.00 (BIOS v. 2.7)
AMD AthlonXP 2500+ (Barton)
PATA Seagate ST3120022A
SATA Seagate ST3200822AS & Silicon Image 3112 chipset
Gentoo Linux |
|
| Back to top |
|
|
I.C.Wiener
Tux's lil' helper
Joined: 25 Jul 2004
Posts: 115
Location: Furtwangen (Germany)
|
| Posted: Thu May 12, 2005 5:04 pm Post subject: |
|
|
I know, besides that equally crappy 0.9 fix there is another unofficial fix which has at least good reading performance.
But as far as I know writing was'n any better ( <20MB/sec). Also when I heard about it 2 or 3 weeks ago, it wasn't tested properly.
So even if your hardware is actually not affected by this mysterious hardware bug you might get your data scrambled by some buggy pice of software. The more patched you try the higher the chance to get your data messed up.
Btw: I'm still using good old 2.6.8 gentoo-sources, as I can't get my webcam running on newer kernels (yet). sata_sil is completly "unfixed", performance is awesome and still there is no data-corruption. |
|
| Back to top |
|
|
El_Goretto
Moderator
Joined: 29 May 2004
Posts: 3174
Location: Paris
|
| Posted: Thu May 12, 2005 5:16 pm Post subject: |
|
|
| I.C.Wiener wrote: | I know, besides that equally crappy 0.9 fix there is another unofficial fix which has at least good reading performance.
But as far as I know writing was'n any better ( <20MB/sec). Also when I heard about it 2 or 3 weeks ago, it wasn't tested properly. |
This is exactly what qnx is talking about. For my personnal use (data storage) this patch would perfect fit.
| I.C.Wiener wrote: | | So even if your hardware is actually not affected by this mysterious hardware bug you might get your data scrambled by some buggy pice of software. The more patched you try the higher the chance to get your data messed up. |
Right, but... The patch is only activated by the detection of "a priori" concerned hardware. So no problem there. Moreover, the original fix intend to prevent "rumored" (do you prefer "not yet end-user constated"?) data corruption. |
|
| Back to top |
|
|
DrWoland
l33t
Joined: 13 Nov 2004
Posts: 603
|
| Posted: Thu May 12, 2005 5:26 pm Post subject: |
|
|
I'm just gonna go get a Promise TX2 :\
_________________
I'm not a Guru, I just ask a lot of questions. |
|
| Back to top |
|
|
I.C.Wiener
Tux's lil' helper
Joined: 25 Jul 2004
Posts: 115
Location: Furtwangen (Germany)
|
| Posted: Thu May 12, 2005 10:06 pm Post subject: |
|
|
I just read some more documentation about this issue and... arrrgs, this whole thing is really starting to piss me off!
I'm getting tired of running to the shop every two month to replace brand new hardware just because of faulty/nonexistent driver-support under linux.
As some ppl mentioned before, the sil-chip is acting somehow strange but inside sata-specifications. So why the hell should I buy a new Controller if it's the hdd that's broken? What's about that 5year warranty Seagate offered when I bought my hdd?!
I'll check that out first. At least they would have to give me an answer whether my two disks are faulty or not, wouldn't they?! |
|
| Back to top |
|
|
I.C.Wiener
Tux's lil' helper
Joined: 25 Jul 2004
Posts: 115
Location: Furtwangen (Germany)
|
| Posted: Tue May 17, 2005 10:29 pm Post subject: |
|
|
ok, that was quite pointless. Sometimes I wonder why companies offer email-support if they don't even read their customer's questions but just copy'n paste some parts of their faq.
However, I skipped those parts involving a windows-driver-update, but tried out those seatools someone mentioned before:
- controller check was skipped as it is not supported
- filsystem checks were skipped because I don't have any fat/ntfs partitions
- everything else completed without errors
Would be nice to see the results on systems that actually experienced data-corruption (if there are any). |
|
| Back to top |
|
|
qnx
l33t
Joined: 25 Jun 2002
Posts: 638
Location: Göteborg, Sweden
|
| Posted: Wed May 18, 2005 9:56 am Post subject: |
|
|
Pretty useless, in other words.. I'm not sure how seatools works but they'd certainly inform if they'd be about to copy ??Gb, cause the users may not have those free Gb's needed on the drive. So how the h... are they gonna check for data corruption else? Sending 2Mb's a time to the disk's cache?! Yeah right...
_________________
Registred Linux user #191143!
Abit NF7-S rev. 2.00 (BIOS v. 2.7)
AMD AthlonXP 2500+ (Barton)
PATA Seagate ST3120022A
SATA Seagate ST3200822AS & Silicon Image 3112 chipset
Gentoo Linux |
|
| Back to top |
|
|
jonnevers
Veteran
Joined: 02 Jan 2003
Posts: 1594
Location: Gentoo64 land
|
| Posted: Wed May 18, 2005 4:16 pm Post subject: |
|
|
| qnx wrote: | | Pretty useless, in other words.. I'm not sure how seatools works but they'd certainly inform if they'd be about to copy ??Gb, cause the users may not have those free Gb's needed on the drive. So how the h... are they gonna check for data corruption else? Sending 2Mb's a time to the disk's cache?! Yeah right... |
strange, I have almost the exact same system specs as you:
| Code: | blue root # hdparm -Tt /dev/sda
/dev/sda:
Timing cached reads: 1388 MB in 2.00 seconds = 693.07 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for d
evice
Timing buffered disk reads: 166 MB in 3.01 seconds = 55.12 MB/sec
HDIO_DRIVE_CMD(null) (wait for flush complete) failed: Inappropriate ioctl for device
|
I haven't noticed any problem with the data i've put on the drive. Then again I only ran the above test because I happened upon this thread.
- Jon |
|
| Back to top |
|
|
qnx
l33t
Joined: 25 Jun 2002
Posts: 638
Location: Göteborg, Sweden
|
| Posted: Wed May 18, 2005 4:42 pm Post subject: |
|
|
Which kernel version?
_________________
Registred Linux user #191143!
Abit NF7-S rev. 2.00 (BIOS v. 2.7)
AMD AthlonXP 2500+ (Barton)
PATA Seagate ST3120022A
SATA Seagate ST3200822AS & Silicon Image 3112 chipset
Gentoo Linux |
|
| Back to top |
|
|
jonnevers
Veteran
Joined: 02 Jan 2003
Posts: 1594
Location: Gentoo64 land
|
| Posted: Wed May 18, 2005 5:12 pm Post subject: |
|
|
| qnx wrote: | | Which kernel version? |
Linux blue 2.6.12-rc3-love1 #1 Tue May 10 11:16:25 EDT 2005 i686 AMD Athlon(tm) AuthenticAMD GNU/Linux
Abit NFS-2 with sil3112 for SATA
| Code: | root #$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ATA Model: Maxtor 6Y120M0 Rev: YAR5
Type: Direct-Access ANSI SCSI revision: 05
|
|
|
| Back to top |
|
|
I.C.Wiener
Tux's lil' helper
Joined: 25 Jul 2004
Posts: 115
Location: Furtwangen (Germany)
|
| Posted: Wed May 18, 2005 5:53 pm Post subject: |
|
|
@jonnevers: You don't have a problem, your drive is not on the blacklist.
@qnx: there is actually a test to check communication between the disk and the controller - sounds pretty much like what we were looking for. Unfortunately just the sil3112 issn't supported, what a surprise...
And remember we don't need to copy several GB of data, we just need to send a block of 16kb the wrong way and it get's corrupted.
On the other hand, who cares if there is data on the disk? You can just read some raw-data (whatever filesystem), save it in ram, write some 1s and 0s and finally restore the original data. Or how would you check for bad sectors? Of course restoring the data might fail, but if that happens the user has other things to worry about :P |
|
| Back to top |
|
|
qnx
l33t
Joined: 25 Jun 2002
Posts: 638
Location: Göteborg, Sweden
|
| Posted: Wed May 18, 2005 8:44 pm Post subject: |
|
|
You're right, I.C. Wiener. As you said that, it seems pretty easy for anyone to check for corruption. Can you see any way for, let's say me, to do this test? We were previously talking about generating a file that *should* get corrupted on affected systems, etc. but nothing was actually done. Sending a couple of KBs sounds easy, maybe some C-code or something would do?
_________________
Registred Linux user #191143!
Abit NF7-S rev. 2.00 (BIOS v. 2.7)
AMD AthlonXP 2500+ (Barton)
PATA Seagate ST3120022A
SATA Seagate ST3200822AS & Silicon Image 3112 chipset
Gentoo Linux |
|
| Back to top |
|
|
I.C.Wiener
Tux's lil' helper
Joined: 25 Jul 2004
Posts: 115
Location: Furtwangen (Germany)
|
| Posted: Thu May 19, 2005 12:19 am Post subject: |
|
|
Hmm, seems we had the same thought at the same time qnx, I actually wrote a little C program just an hour ago...
| Code: |
* Data FIS maximum payload size is 8k, or 16 blocks. And siimage
controllers doesn't split packets on odd boundaries (maybe not at all)
when data size is equal to or less than 15 blocks. So, sata_sil driver
sets max_sectors to 15, and the drive never gets to transfer more than
one page at a time. So, it's dog slow.
|
I thought it would be simple to write some huge arrays of junk-data to a file (in the pattern specified above), read from the file and compare it's content, but it turned out to be not that trivial.
Although the sil-chip hasn't any memory attached, the data I'm writing gotta be cached somewhere. Every few sec. there was a burst-write of a few MB and I guess it didn't even read from disk but kept the file in ram. It seems almost impossible to write data in a special pattern if the driver collects data half the day and writes it a few hours later. Any Ideas?
Is there a way to set cache-mode to write-through instead of write-back?
ps: this is not a matter of filesize. Bigger files just cause heavy cpu-load (and also disk-load) but the data is buffered and written in huge blocks (btw. amazing speed, 83MB/sec.). And unless I generate files larger than 1GB, I think I'll always get a clean copy which was kept in ram. |
|
| Back to top |
|
|
qnx
l33t
Joined: 25 Jun 2002
Posts: 638
Location: Göteborg, Sweden
|
| Posted: Thu May 19, 2005 4:32 am Post subject: |
|
|
Oh, cool
Ok, let's see.. There's no possibility of using dd for this than, is it? Cause it is the OS itself that causes cacheing?
I think you can disable write-back in BIOS, though I'm not sure, but check that.
And what about generating files larger than your RAM? I have just 512Mb for example, so the file won't be abnormally big.
Btw, I have already copied some of such files (have ripped some of my movies to xvid), and they end up at 700-800 Mb usualy. When I did some testing, some time ago, I copied that backup partition to the new SATA drive and back, about 10 times and checked then some of the movies with md5. Nothing happend.
Still it would be nice with a general testing program, so if you want to send me a link or e-mail the source!
Cheers!
_________________
Registred Linux user #191143!
Abit NF7-S rev. 2.00 (BIOS v. 2.7)
AMD AthlonXP 2500+ (Barton)
PATA Seagate ST3120022A
SATA Seagate ST3200822AS & Silicon Image 3112 chipset
Gentoo Linux |
|
| Back to top |
|
|
qnx
l33t
Joined: 25 Jun 2002
Posts: 638
Location: Göteborg, Sweden
|
| Posted: Thu May 19, 2005 4:03 pm Post subject: |
|
|
Btw, it seems like you (I.C.Wiener) know more about your system setup than I do about mine. What I've figured out is that I have 3112 and my disk of course. But no idea about the revision or firmware, where did you get that?
Here's what my chipset says:
| Code: |
SiL 3112ACT114
Q23144.1
0252
1.21
|
Any idea what those number represent?
I tried a couple of times to get a corruption, and you must be trying harder since both your disks are SATA..right? Neither of us "succeeded" still. Both of us have upgraded the BIOS to latest version avalible. (I was trying to find a changelog of the SATA BIOS, but couldn't. All I can see is that my MoBo BIOS has the 4.2.5.0 version of that SATA BIOS-thing..)
I'm trying to find out if we really are affected by this, which version/revision of chipset it is about, etc. Still, with the latest fix I don't see any performance decrease, so I'm happy as it is now =)
_________________
Registred Linux user #191143!
Abit NF7-S rev. 2.00 (BIOS v. 2.7)
AMD AthlonXP 2500+ (Barton)
PATA Seagate ST3120022A
SATA Seagate ST3200822AS & Silicon Image 3112 chipset
Gentoo Linux |
|
| Back to top |
|
|
I.C.Wiener
Tux's lil' helper
Joined: 25 Jul 2004
Posts: 115
Location: Furtwangen (Germany)
|
| Posted: Thu May 19, 2005 4:33 pm Post subject: |
|
|
First, that program I wrote is useless, as the OS buffers the data before writing and thus writes it in a different pattern. I would have to run it on a stupid OS like DOS for example and use the old Int13-method to write data. But uhh, I'm too lazy to get a compiler, create a boot disc, delete one of my ext3 partitions to get some space for DOS,...
you can get your drives firmware revision and some other information with dmesg:
| Code: |
libata version 1.02 loaded.
sata_sil version 0.54
ACPI: PCI interrupt 0000:01:0c.0[A] -> GSI 16 (level, high) -> IRQ 16
ata1: SATA max UDMA/100 cmd 0xF9809080 ctl 0xF980908A bmdma 0xF9809000 irq 16
ata2: SATA max UDMA/100 cmd 0xF98090C0 ctl 0xF98090CA bmdma 0xF9809008 irq 16
ata1: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata1: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48
ata1: dev 0 configured for UDMA/100
scsi0 : sata_sil
ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4003 85:3469 86:3c01 87:4003 88:207f
ata2: dev 0 ATA, max UDMA/133, 390721968 sectors: lba48
ata2: dev 0 configured for UDMA/100
scsi1 : sata_sil
Using anticipatory io scheduler
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: ST3200822AS Rev: 3.01
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sda: drive cache: write back
/dev/scsi/host0/bus0/target0/lun0: p1 p2 p3
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 390721968 512-byte hdwr sectors (200050 MB)
SCSI device sdb: drive cache: write back
/dev/scsi/host1/bus0/target0/lun0: p1
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
|
To get the controller's rev. I just looked inside :P
My mainboard bios is from 2003, I tried to update, but my PC crashed during flashing.
And yes I copied some large amounts of data between my 2 discs and checked md5sums - no corruption.
However when copying data between the 2 discs performance on the sil sucks anyway. I can't get more than 30MB/sec (without any fix applied). Some windows user's complained about this behaviour, too.
Read-performance should not be affected by recent fixes, but I think write-performance issn't any better yet, is it? |
|
| Back to top |
|
|
mcfly.587
Tux's lil' helper
Joined: 29 Mar 2005
Posts: 118
|
| Posted: Tue May 24, 2005 6:53 pm Post subject: |
|
|
Same for mee :
| Code: | bash-2.05b# hdparm -t /dev/hde
/dev/hde:
Timing buffered disk reads: 52 MB in 3.11 seconds = 16.70 MB/sec
bash-2.05b# hdparm -c1d1X69 /dev/hde
/dev/hde:
setting 32-bit IO_support flag to 1
setting using_dma to 1 (on)
setting xfermode to 69 (UltraDMA mode5)
IO_support = 1 (32-bit)
using_dma = 1 (on)
bash-2.05b# hdparm -t /dev/hde
/dev/hde:
Timing buffered disk reads: 50 MB in 3.00 seconds = 16.65 MB/sec |
2* Sata Seagate ST3120026AS 120 go
Same controler with my other disk ( 2* raptors 36 go ) :
| Code: | bash-2.05b# hdparm -t /dev/hdi
/dev/hdi:
Timing buffered disk reads: 188 MB in 3.02 seconds = 62.26 MB/sec
|
  no solution at this moment ?
My kernel config :
[*] Support for SATA (deprecated; conflicts with libata SATA driver)
<*> Silicon Image chipset support
Revision of controler : 4.2.12 i think ... |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
