From: Andre Przywara
[ Upstream commit 24201a64770afe2e17050b2ab9e8c0e24e9c23b2 ]
The DMA error handler routine is currently a tasklet, scheduled to run
after the DMA error IRQ was handled.
However it needs to take the MDIO mutex, which is not allowed to do in a
tasklet. A kernel (with debug
From: Andre Przywara
[ Upstream commit 24201a64770afe2e17050b2ab9e8c0e24e9c23b2 ]
The DMA error handler routine is currently a tasklet, scheduled to run
after the DMA error IRQ was handled.
However it needs to take the MDIO mutex, which is not allowed to do in a
tasklet. A kernel (with debug
(DMA is only optional) and also avoid printing twice an error
when a real DMA error is happening.
On top of that, dev_err_probe from Krzysztof has been rebased.
[1] https://marc.info/?l=linux-i2c&m=159741480608578&w=2
[2] https://marc.info/?l=linux-i2c&m=159973040314193&w=2
Alain V
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Larry Finger
commit 2823c8716c687d6c7e261a3a02b3cab43809fe9c upstream.
In commit 66cffd6daab7 ("b43: fix transmit failure when VT is switched"),
a condition is noted where the network controll
Return buffer to V4L2 in error state if DMA error occurs.
Signed-off-by: Hugues Fruchet
---
drivers/media/platform/stm32/stm32-dcmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c
b/drivers/media/platform/stm32/stm32-dcmi.c
index a3fbfac
The patch
ASoC: stm32: spdifrx: fix control DMA error management
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours
Fix DMA channel request error handling.
Signed-off-by: Olivier Moysan
---
sound/soc/stm/stm32_spdifrx.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/sound/soc/stm/stm32_spdifrx.c b/sound/soc/stm/stm32_spdifrx.c
index d7dbe84..b9bdefc 100644
--- a/sound/soc/
On Wed, Sep 27, 2017 at 10:13:51AM -0700, Dan Williams wrote:
> As far as I can see "Offset can be greater than PAGE_SIZE" is the only
> safe assumption for core code.
It seems completely bogus to me, but if it is the current assumption
we'll have to document it. But this brings me back to that
o
On 28-09-2017 18:35, Raj, Ashok wrote:
> Thanks for trying that Harsh.
>
> sp_off turns of super page support. Which this mode, do you still see offsets
> greater than 4k?
Yes, offset greater than 4k is still there. Refer below.
[56732.774872] offset 4110 len 76 dma addr 3a531200e dma len 76
[56
Thanks for trying that Harsh.
sp_off turns of super page support. Which this mode, do you still see offsets
greater than 4k?
On Thu, Sep 28, 2017 at 07:08:21PM +0530, Harsh Jain wrote:
>
>
> Today I tried with "Intel_iommu=sp_off" boot option. Traffic runs without any
> error for more than 1
On 28-09-2017 02:59, Casey Leedom wrote:
> Hey Raj,
>
> Let us know if you need help in gathering more debugging information. For
> the time being we've decided to ERRATA the use of the Intel I/O MMU with
> IPsec till we Root Cause the issue. But this is still at the top of Harsh's
> bug list
On Wed, Sep 27, 2017 at 10:13:04PM +, Casey Leedom wrote:
> | From: Raj, Ashok
> | Sent: Wednesday, September 27, 2017 12:07 PM
> |
> | looking at the debug output i got from Harsh it still looks like a bug in
> | the code.
> |
> | [ 538.284589] __domain_mapping nr_pages 0x1
> | [ 538.284600]
On 28-09-2017 03:43, Casey Leedom wrote:
> | From: Raj, Ashok
> | Sent: Wednesday, September 27, 2017 12:07 PM
> |
> | looking at the debug output i got from Harsh it still looks like a bug in
> | the code.
> |
> | [ 538.284589] __domain_mapping nr_pages 0x1
> | [ 538.284600] __domain_mapping sg
| From: Raj, Ashok
| Sent: Wednesday, September 27, 2017 12:07 PM
|
| looking at the debug output i got from Harsh it still looks like a bug in
| the code.
|
| [ 538.284589] __domain_mapping nr_pages 0x1
| [ 538.284600] __domain_mapping sg_res 0x1 sg->dma_address 0xf291000e dma len
| 0x38 pteval
Hi Casey
looking at the debug output i got from Harsh it still looks like
a bug in the code.
[ 538.284589] __domain_mapping nr_pages 0x1
[ 538.284600] __domain_mapping sg_res 0x1 sg->dma_address 0xf291000e dma len
0x38 pteval 0x3cbce3003 phys_pfn 0x3cbce3
[ 538.284604] chelsio driver - offse
Hey Raj,
Let us know if you need help in gathering more debugging information. For
the time being we've decided to ERRATA the use of the Intel I/O MMU with
IPsec till we Root Cause the issue. But this is still at the top of Harsh's
bug list.
With Robin's comments, I'm almost sure that the:
Hi Robin
On Wed, Sep 27, 2017 at 06:18:02PM +0100, Robin Murphy wrote:
> On Wed, 27 Sep 2017 16:31:04 +
> Casey Leedom wrote:
>
> > | From: Dan Williams
> > | Sent: Tuesday, September 26, 2017 9:10 AM
> > |
> > | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom
> > wrote: | > | From: Robin
| From: Robin Murphy
| Sent: Wednesday, September 27, 2017 10:18 AM
|
| From my experience, in general terms each scatterlist segment
| represents some contiguous quantity of pages, of which sg->page is the
| first, while sg->length and sg->offset describe the specific bounds of
| that segment's
On Wed, 27 Sep 2017 16:31:04 +
Casey Leedom wrote:
> | From: Dan Williams
> | Sent: Tuesday, September 26, 2017 9:10 AM
> |
> | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom
> wrote: | > | From: Robin Murphy
> | > | Sent: Tuesday, September 26, 2017 7:22 AM
> | > |...
> | > ...
> | >
On Wed, Sep 27, 2017 at 9:31 AM, Casey Leedom wrote:
> | From: Dan Williams
> | Sent: Tuesday, September 26, 2017 9:10 AM
> |
> | On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom wrote:
> | > | From: Robin Murphy
> | > | Sent: Tuesday, September 26, 2017 7:22 AM
> | > |...
> | > ...
> | > Regard
| From: Dan Williams
| Sent: Tuesday, September 26, 2017 9:10 AM
|
| On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom wrote:
| > | From: Robin Murphy
| > | Sent: Tuesday, September 26, 2017 7:22 AM
| > |...
| > ...
| > Regardless, it seems that you agree that there's an issue with the Intel
|
So just to be 100% sure I understand the patch you're proposing, you got
the first use of VTD_PAGE_SHIFT wrong; it should have been VTD_PAGE_MASK? I.e.
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 6784a05..d43b566 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/dr
On 26/09/17 15:34, Raj, Ashok wrote:
> On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote:
>> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
>> index 6784a05dd6b2..d7f7def81613 100644
>> --- a/drivers/iommu/intel-iommu.c
>> +++ b/drivers/iommu/intel-iommu.c
>> @@ -
| From: Robin Murphy
| Sent: Tuesday, September 26, 2017 7:22 AM
|
| On 26/09/17 13:21, Harsh Jain wrote:
| > Find attached new set of log. After repeated tries it panics.
|
| Thanks, that makes things a bit clearer - looks like fixing the physical
| address/pteval calculation to not be off by a p
Oops..minor typo.. VTD_PAGE_SHIFT instead of VTD_PAGE_MASK
On Tue, Sep 26, 2017 at 07:34:41AM -0700, Ashok Raj wrote:
> On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote:
> > diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> > index 6784a05dd6b2..d7f7def81613 100
On Tue, Sep 26, 2017 at 03:22:47PM +0100, Robin Murphy wrote:
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index 6784a05dd6b2..d7f7def81613 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -2254,10 +2254,12 @@ static int __domain_mapp
On Tue, Sep 26, 2017 at 9:06 AM, Casey Leedom wrote:
> | From: Robin Murphy
> | Sent: Tuesday, September 26, 2017 7:22 AM
>
> |
> | On 26/09/17 13:21, Harsh Jain wrote:
> | > Find attached new set of log. After repeated tries it panics.
> |
> | Thanks, that makes things a bit clearer - looks like
On 26/09/17 13:21, Harsh Jain wrote:
> Find attached new set of log. After repeated tries it panics.
Thanks, that makes things a bit clearer - looks like fixing the physical
address/pteval calculation to not be off by a page in one direction wasn't
helping much because the returned DMA address is
On 26-09-2017 01:41, Dan Williams wrote:
> On Mon, Sep 25, 2017 at 1:05 PM, Casey Leedom wrote:
>> | From: Dan Williams
>> | Sent: Monday, September 25, 2017 12:31 PM
>> | ...
>> | IIUC it looks like this has been broken ever since commit e1605495c716
>> | "intel-iommu: Introduce domain_sg_mapp
Find attached new set of log. After repeated tries it panics.
On 26-09-2017 09:16, Harsh Jain wrote:
> On 26-09-2017 00:16, Casey Leedom wrote:
>> | From: Raj, Ashok
>> | Sent: Monday, September 25, 2017 8:54 AM
>> |
>> | Not sure how the page->offset would end up being greater than page-size?
>
>> entry with page->offset > 4096 (PAGE_SIZE). It starts giving DMA
>> error. Without IOMMU it works fine.
>>
>> This is not a bug. The network stack can and will feed us such
>> SG lists.
> Hm? Under what circumstances is the offset permitted to be
On 26-09-2017 00:16, Casey Leedom wrote:
> | From: Raj, Ashok
> | Sent: Monday, September 25, 2017 8:54 AM
> |
> | Not sure how the page->offset would end up being greater than page-size?
Refer below
> |
> | If you have additional traces, please send them by.
> |
> | Is this a new driver? wonderi
| From: Raj, Ashok
| Sent: Monday, September 25, 2017 12:03 PM
|
| On Mon, Sep 25, 2017 at 01:11:04PM -0700, Dan Williams wrote:
| > On Mon, Sep 25, 2017 at 1:05 PM, Casey Leedom wrote:
| > > | From: Dan Williams
| > > | Sent: Monday, September 25, 2017 12:31 PM
| > > | ...
| > > | IIUC it lo
Hi
On Mon, Sep 25, 2017 at 01:11:04PM -0700, Dan Williams wrote:
> On Mon, Sep 25, 2017 at 1:05 PM, Casey Leedom wrote:
> > | From: Dan Williams
> > | Sent: Monday, September 25, 2017 12:31 PM
> > | ...
> > | IIUC it looks like this has been broken ever since commit e1605495c716
> > | "intel-iom
by driver has some
| > entry with page->offset > 4096 (PAGE_SIZE). It starts giving DMA
| > error. Without IOMMU it works fine.
| >
| > This is not a bug. The network stack can and will feed us such
| > SG lists.
|
| Hm? Under what circumstances is the offset permitted to be >
|
On Mon, Sep 25, 2017 at 1:05 PM, Casey Leedom wrote:
> | From: Dan Williams
> | Sent: Monday, September 25, 2017 12:31 PM
> | ...
> | IIUC it looks like this has been broken ever since commit e1605495c716
> | "intel-iommu: Introduce domain_sg_mapping() to speed up
> | intel_map_sg()". I.e. it loo
| From: Dan Williams
| Sent: Monday, September 25, 2017 12:31 PM
| ...
| IIUC it looks like this has been broken ever since commit e1605495c716
| "intel-iommu: Introduce domain_sg_mapping() to speed up
| intel_map_sg()". I.e. it looks like the calculation for pte_val should
| be:
|
| pteval =
n chelsio crypto driver we
> | >> observed that when scatter/gather list received by driver has
> | >> some entry with page->offset > 4096 (PAGE_SIZE). It starts
> | >> giving DMA error. Without IOMMU it works fine.
> | >
> | > This is not a bug. The networ
| From: Raj, Ashok
| Sent: Monday, September 25, 2017 8:54 AM
|
| Not sure how the page->offset would end up being greater than page-size?
|
| If you have additional traces, please send them by.
|
| Is this a new driver? wondering how we didn't run into this?
According to Herbert Xu and one of
On Wed, 2017-09-20 at 16:01 +0800, Herbert Xu wrote:
> Harsh Jain wrote:
> >
> > While debugging DMA mapping error in chelsio crypto driver we
> observed that when scatter/gather list received by driver has some
> entry with page->offset > 4096 (PAGE_SIZE). It starts g
> | >>
> | >> While debugging DMA mapping error in chelsio crypto driver we
> | >> observed that when scatter/gather list received by driver has
> | >> some entry with page->offset > 4096 (PAGE_SIZE). It starts
> | >> giving DMA error. Without IOM
has
| >> some entry with page->offset > 4096 (PAGE_SIZE). It starts
| >> giving DMA error. Without IOMMU it works fine.
| >
| > This is not a bug. The network stack can and will feed us such
| > SG lists.
| >
| >> 2) It cannot be driver's responsibilty to upd
On 20-09-2017 13:31, Herbert Xu wrote:
> Harsh Jain wrote:
>> While debugging DMA mapping error in chelsio crypto driver we observed that
>> when scatter/gather list received by driver has some entry with page->offset
>> > 4096 (PAGE_SIZE). It starts giving DMA err
page->offset > 4096 (PAGE_SIZE). It starts giving DMA error. Without IOMMU
>>> it works fine.
>> This is not a bug. The network stack can and will feed us such
>> SG lists.
>>
>>> 2) It cannot be driver's responsibilty to update received sg entries to
On 20/09/17 09:01, Herbert Xu wrote:
> Harsh Jain wrote:
>>
>> While debugging DMA mapping error in chelsio crypto driver we observed that
>> when scatter/gather list received by driver has some entry with page->offset
>> > 4096 (PAGE_SIZE). It starts giving D
Harsh Jain wrote:
>
> While debugging DMA mapping error in chelsio crypto driver we observed that
> when scatter/gather list received by driver has some entry with page->offset
> > 4096 (PAGE_SIZE). It starts giving DMA error. Without IOMMU it works fine.
This is not a
Hi,
While debugging DMA mapping error in chelsio crypto driver we observed that
when scatter/gather list received by driver has some entry with page->offset >
4096 (PAGE_SIZE). It starts giving DMA error. Without IOMMU it works fine.
Before reaching to chelsio crypto driver(driver/
The patch
spi: stm32: enhance DMA error management
has been applied to the spi tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus
This patch reworks DMA error management. In case the DMA callback is
called while EOT (End Of Transfer) flag is not set, that means that DMA
encountered an error. This error will result in an auto-suspend of SPI
flow, which could also result in an overrun. So, in DMA mode, SUSP and
OVR flags are a
This patch reworks DMA error management. In case the DMA callback is
called while EOT (End Of Transfer) flag is not set, that means that DMA
encountered an error. This error will result in an auto-suspend of SPI
flow, which could also result in an overrun. So, in DMA mode, SUSP and
OVR flags are a
/drivers/vme/bridges/vme_ca91cx42.c
@@ -1269,6 +1269,7 @@ static int ca91cx42_dma_list_exec(struct vme_dma_list
*list)
dev_err(dev, "ca91c042: DMA Error. DGCS=%08X\n", val);
val = ioread32(bridge->base + DCTL);
+ retval = -EIO;
/drivers/vme/bridges/vme_ca91cx42.c
@@ -1269,6 +1269,7 @@ static int ca91cx42_dma_list_exec(struct vme_dma_list
*list)
dev_err(dev, "ca91c042: DMA Error. DGCS=%08X\n", val);
val = ioread32(bridge->base + DCTL);
+ retval = -EIO;
On Fri, Sep 19, 2014 at 04:29:19PM -0400, David Miller wrote:
> From: Neil Horman
> Date: Wed, 17 Sep 2014 09:04:44 -0400
>
> > Noted that 3c59x has no checks on transmit for failed DMA mappings, and no
> > ability to unmap fragments when a single map fails in the middle of a
> > transmit.
> > T
From: Neil Horman
Date: Wed, 17 Sep 2014 09:04:44 -0400
> Noted that 3c59x has no checks on transmit for failed DMA mappings, and no
> ability to unmap fragments when a single map fails in the middle of a
> transmit.
> This patch provides error checking to ensure that dma mappings work properly,
Noted that 3c59x has no checks on transmit for failed DMA mappings, and no
ability to unmap fragments when a single map fails in the middle of a transmit.
This patch provides error checking to ensure that dma mappings work properly,
and unrolls an skb mapping if a fragmented skb transmission has a
Noted that 3c59x has no checks on transmit for failed DMA mappings, and no
ability to unmap fragments when a single map fails in the middle of a transmit.
This patch provides error checking to ensure that dma mappings work properly,
and unrolls an skb mapping if a fragmented skb transmission has a
After TX dma completes the code will queue another DMA transfer. If
serial8250_tx_dma() fails then there is no plan B to continue the
transfer manually.
This patch enables the TX-fifo empty event so it can be tried again via
DMA or use the manual fallback in case it fails.
Cc: Heikki Krogerus
Cc:
atl1e: fix dma mapping warnings") was missing a bit of code.
Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation. This patch fixes that up. It also remembers to free the
skb in the event that
("atl1e: fix dma mapping warnings") was missing a bit of code.
Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation. This patch fixes that up. It also remembers to free the
skb in the even
atl1e: fix dma mapping warnings") was missing a bit of code.
Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation. This patch fixes that up. It also remembers to free the
skb in the even
atl1e: fix dma mapping warnings") was missing a bit of code.
Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation. This patch fixes that up. It also remembers to free the
skb in the event that
atl1e: fix dma mapping warnings") was missing a bit of code.
Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation. This patch fixes that up. It also remembers to free the
skb in the event that
On Wed, Feb 06, 2008 at 09:54:53AM +0100, Marc Donner wrote:
> and how do i disable dma? it is the installer image, and no hdparm is
> availible. and the ide=nodma boot parameter seems not to work.
ide=nodma works for me on 2.6.18. I think on newer kernels you need
hda=nodma which is nice since
On Tuesday 05 February 2008, you wrote:
> On Tue, Feb 05, 2008 at 06:52:29PM +0100, Marc Donner wrote:
> > hi,
> >
> > i have a problem using a cf card with an ide adapter.
> > using debian kernel 2.6.18-5
> >
>
> Adapter doesn't support DMA, but controller and CF cards do. To fix,
> tell the syst
On Tue, Feb 05, 2008 at 06:52:29PM +0100, Marc Donner wrote:
> hi,
>
> i have a problem using a cf card with an ide adapter.
> using debian kernel 2.6.18-5
>
> on boot:
> Feb 5 17:38:06 kernel: hdd: max request size: 128KiB
> Feb 5 17:38:06 kernel: hdd: 2000880 sectors (1024 MB) w/2KiB Cache,
hi,
i have a problem using a cf card with an ide adapter.
using debian kernel 2.6.18-5
on boot:
Feb 5 17:38:06 kernel: hdd: max request size: 128KiB
Feb 5 17:38:06 kernel: hdd: 2000880 sectors (1024 MB) w/2KiB Cache,
CHS=1985/16/63, UDMA(33)
Feb 5 17:38:06 kernel: hdd:<4>hdd: dma_timer_exp
Bartlomiej Zolnierkiewicz wrote:
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Bartlomiej Zolnierkiewicz wrote:
Make cdrom_newpc_intr() match cdrom_{read,write}_intr() w.r.t.
handling DMA errors:
* disable DMA before cdrom_decode_status() call
* log the device name and the type of the request (read/write)
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]
if (dma_error) {
- printk(KERN_ERR "ide-cd: dma error\n");
- ide_dma_off(drive);
+ if (dma_error)
return ide_error(drive, "dma error", stat);
- }
end_that_reques
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/ide-cd.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: b/drivers/ide/ide-cd.c
===
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd
) |
PHB_PLSSR_OFFSET);
+ plssr = be32_to_cpu(readl(target));
/* If no error, the agent ID in the CSR is not valid */
printk(KERN_EMERG "Calgary: DMA error on Calgary PHB 0x%x, "
- "CSR = 0x%08x\n", tbl->it_busno, val32);
+ "[EMAIL
Hi,
Was there any change in the PCI initialization code between versions
2.4.0-test8 and 2.4.2.?
I am working on a card and for the same register settings of the card, DMA
from host memory to card memory is successfull for the 2.4.0-test8 but on
2.4.2 kernel, the data transfer is successfull but
Mike Panetta wrote:
> hdi: timeout waiting for DMA
> ide_dmaproc: chipset supported ide_dma_timeout func only: 14
> hdi: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
> hdi: DMA disabled
> ide4: reset: success
>
> I get this message on all my off board HPT366 based controller
What could cause this error?
hdi: timeout waiting for DMA
ide_dmaproc: chipset supported ide_dma_timeout func only: 14
hdi: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdi: DMA disabled
ide4: reset: success
I get this message on all my off board HPT366 based controller
card
> Nevertheless I checked the partition with my old SuSE 2.2.16 kernel
> and it gave a different error message:
>
> hda: read_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
> hda: read_intr: error=0x40 { UncorrectableError } LBAsect = 2421754, sector
> 210048
> end_request: I/O er
Hi kernel hackers,
okay possibly my HD is the problem and I will try to check the disc
with a Seagate tool (damned, i.e. reinstalling Windows) or even
reformating I everything else goes wrong.
Nevertheless I checked the partition with my old SuSE 2.2.16 kernel
and it gave a different error messa
> Fsck discovered an error it wasn't able to fix. This error never
> appeared before and my Seagate HD actually should be alright.
Umm the error says not
> hda: dma_intr: status=0x51 { DriveReady SeekCompleteError }
> hda: dma_intr: error=0x40 { UncorrectableError } LBAsect = 2421754, sector
> 2
Hi,
recently I was on the internet with kernel 2.4.0-prerelease.
Suddenly Netscape hung and I couldn't help hard rebooting.
Fsck discovered an error it wasn't able to fix. This error never
appeared before and my Seagate HD actually should be alright.
The following error message appears everytim
78 matches
Mail list logo
