[opensuse] Help! RO File System Lock down OpenSUSE 10.2
Hi all, I must be quick, before the system locks down again. It seems that since I installed OpenSUSE 10.2 and used ext3 FS, I get system Lockdowns with the File System going Read Only suddenly. At bootup the ext3 rollback of journals seem to be doing something, even if the shut down was done normally. There seems to be a correlation to high disk access, which occurs when either Evolution, KMail (Kontact) or Gimp loads and saves files on a default ext3 OpenSUES 10.2 root system, with a reiserfs partition mounted on /home/<user>/Data/Data1 and/or a xfs on /home/<user>/Data/Data2, where the data is. Can using different FS's in one system cause such problems? How can I find out what causes it? :-(( Al -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* LLLActive@GMX.Net
It seems that since I installed OpenSUSE 10.2 and used ext3 FS, I get system Lockdowns with the File System going Read Only suddenly. At bootup the ext3 rollback of journals seem to be doing something, even if the shut down was done normally.
There seems to be a correlation to high disk access, which occurs when either Evolution, KMail (Kontact) or Gimp loads and saves files on a default ext3 OpenSUES 10.2 root system, with a reiserfs partition mounted on /home/<user>/Data/Data1 and/or a xfs on /home/<user>/Data/Data2, where the data is. Can using different FS's in one system cause such problems?
How can I find out what causes it?
First think I would do is boot from a live cd and check for free space on your file systems. It really sounds like hardware failing. You may be loosing a hard-drive ?? -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue June 19 2007 17:11, LLLActive@GMX.Net wrote: <snip>
... Can using different FS's in one system cause such problems?
Theoretically, no, but in actual fact there are circumstances where conflicts *can* arise. In my case... with this specific chipset and corresponding kernel IDE controller module... cache buffering is enabled or disabled on a per drive basis. Running disparate filesystem types in adjacent partitions on the same drive (i.e. reiserfs + ext3) triggered errors comparable to those you're experiencing now. I ultimately coaxed those errors away permanently by standardizing my installations to using only one journaling filesystem type per drive. hth & regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tuesday 19 June 2007 23:47:43 Carl Hartung wrote:
On Tue June 19 2007 17:11, LLLActive@GMX.Net wrote: <snip>
... Can using different FS's in one system cause such problems?
Theoretically, no, but in actual fact there are circumstances where conflicts *can* arise.
In my case... with this specific chipset and corresponding kernel IDE controller module... cache buffering is enabled or disabled on a per drive basis. Running disparate filesystem types in adjacent partitions on the same drive (i.e. reiserfs + ext3) triggered errors comparable to those you're experiencing now.
I ultimately coaxed those errors away permanently by standardizing my installations to using only one journaling filesystem type per drive.
hth & regards,
Carl
Thanx Carl & Partick, Patrick, my filesystem had enough space. Failing drives has crossed my mind. I have in fact had this problem on three very different systems now, so no drive failures I guess. As Carl seems to suggest, and the fact is, I have been using different FS's on these maschines since OpenSUSE changed to the default ext3. I just wanted to test them all. I will have to change all to one system I think. Is there a way to convert xfs & reiser to ext3 or the other way around? Which filesystem is best to use nowadays? I have many small files, so which is better and most stable? Is reiserfs still recommendable? It has not given me problems before. Why has OpenSUSE gone away from reiserfs as default? :-/ Al -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
* LLLActive@GMX.Net
Patrick, my filesystem had enough space. Failing drives has crossed my mind. I have in fact had this problem on three very different systems now, so no drive failures I guess. As Carl seems to suggest, and the fact is, I have been using different FS's on these maschines since OpenSUSE changed to the default ext3. I just wanted to test them all. I will have to change all to one system I think. Is there a way to convert xfs & reiser to ext3 or the other way around?
don't know much about converters. I would format a temporary area and store files while reformatting the original area to whichever format you decide is best for you. There are many opinions and you know about opinions :^)
Which filesystem is best to use nowadays? I have many small files, so which is better and most stable?
I got bitten by reiser some years ago and .... I use ext3 now and will switch to ext4 when it is available.
Is reiserfs still recommendable? It has not given me problems before. Why has OpenSUSE gone away from reiserfs as default?
I believe that support for v3 is lacking and v4 is not ready ?? I have nearly 1.5 TB in 7 hard drives of various sizes and seldom reboot. I have had *no* (fingers crossed) problems with ext3 in the last three years. I'm an *old* horse and hesitate to change :^) gud luk -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Tue June 19 2007 6:31 pm, Patrick Shanahan scratched these words onto a coconut shell, hoping for an answer:
* LLLActive@GMX.Net
[06-19-07 18:18]: <snip> don't know much about converters. I would format a temporary area and store files while reformatting the original area to whichever format you decide is best for you.
The only thing I ever heard about converters was "be certain sure that you have a good ( restorable back up ) that was eons ago but it's probably good advice anyway
There are many opinions and you know about opinions :^) Yup , we all got em ;-)
Which filesystem is best to use nowadays? I have many small files, so which is better and most stable?
I got bitten by reiser some years ago and .... I use ext3 now and will switch to ext4 when it is available. Ditto on bitten. I usually have lots of stuff in huge files , I*was*using JFS which worked a treat.. since Suse isn't using it any more I went w/ XFS on this box haven't had any problems w/ the file system that wasn't PEBKAC , your mileage etc.
Is reiserfs still recommendable? It has not given me problems before. Why has OpenSUSE gone away from reiserfs as default?
I believe that support for v3 is lacking and v4 is not ready ?? And the owner /maintainer being charged w/ his wife's murder didn't instil a lot of confidence. He is going to be busy for a long time even if he gets aquitted. I have nearly 1.5 TB in 7 hard drives of various sizes and seldom reboot. I have had *no* (fingers crossed) problems with ext3 in the last three years. I'm an *old* horse and hesitate to change :^) Wheiw, I thought I was the one who couldn't let go of *stuff* ;-)
-- j I've lived in the real world enough, we're all here because we ain't all there. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-06-19 at 20:04 -0400, jfweber@ wrote:
I believe that support for v3 is lacking and v4 is not ready ?? And the owner /maintainer being charged w/ his wife's murder didn't instil a lot of confidence. He is going to be busy for a long time even if he gets aquitted.
That doesn't affect us (yet), because the distro only has version 3, and he doesn't maintain version 3: he was only involved in developing version 4: ie, once reiserfs V3 got integrated into the kernel he abandoned it (AFAIK) and concentrated in V4. The maintenance of V3 was and is done by SuSE/Novell personnel, in fact. Thus anything he does or doesn't, even his personal problems, does not affect the currently used version of reiserfs reliability at all. As for the reasons you asked for resiserfs no longer being the default choice in opensuse, they are on record since many months; ie, they were posted here or another related list. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGeHmOtTMYHG2NR9URAsETAKCPfyTzCeE9wTl/Ib/lesyyjKPxCgCfQ2vr yQBJNbgkfWDfaSN/6TJ/Hy0= =qQiA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2007-06-19 at 23:11 +0200, LLLActive@ wrote:
Can using different FS's in one system cause such problems?
No.
How can I find out what causes it?
Check for HD failure, use the manufacturer test suite or smartctl. Check the logs. Is it scsi? Is it PATA, with 80 wire parallel cable? Replace it with a new one. They are fragile. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGeFTCtTMYHG2NR9URArbIAJsGp+ZHZ2gaP6DihNBx3CMEpKxPxwCfXvOs u2b7lJzejNaGxd7LhplBIdw= =P91b -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi all,
I must be quick, before the system locks down again. I recalled this problem was reported last month -- thread "File system becomes read-only", to which you contributed. No solution was posted to
On 06/19/2007 03:11 PM, LLLActive@GMX.Net wrote: the list, no one mentioned anything about a bug report, and I cannot find any bug report summaries that look even remotely close to the problem.
It seems that since I installed OpenSUSE 10.2 and used ext3 FS, I get system Lockdowns with the File System going Read Only suddenly. At bootup the ext3 rollback of journals seem to be doing something, even if the shut down was done normally.
There seems to be a correlation to high disk access, which occurs when either Evolution, KMail (Kontact) or Gimp loads and saves files on a default ext3 OpenSUES 10.2 root system, with a reiserfs partition mounted on /home/<user>/Data/Data1 and/or a xfs on /home/<user>/Data/Data2, where the data is. Can using different FS's in one system cause such problems?
How can I find out what causes it?
I tend to doubt that the specific filesystem(s) in use have anything at all to do with this, but the high disk access probably does. There is a thread on Dell about problems with the MegaRAID sas driver (module name megasas) -- http://lists.us.dell.com/pipermail/linux-poweredge/2007-March/029974.html -- but you have not given enough information for anyone to know if this is relevant to your problem. Grep /var/log/messages for "megasas". One writer in that thread (on Dell) writes "the problem is that the Linux kernel's SCSI layer insists on a single timeout for all SCSI requests, and doesn't tolerate high variances in command completion times. If any single command times out, it resets the whole bus, even if there is still significant activity." This suggests that the problem is more widespread than just a RAID issue. This is that writer's message -- http://lists.us.dell.com/pipermail/linux-poweredge/2007-March/029982.html -- and it contains a suggestion that may be of use to you. You'll need to give us a lot more information about your system hardware (including the modules that are loaded for hard drive i/o), plus information from /var/log/messages about what is happening when the filesystem goes RO. -- Hypocrisy is the homage vice pays to virtue. -- François de La Rochefoucauld -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed 20 June 2007 00:56, Darryl Gregorash wrote:
On 06/19/2007 03:11 PM, LLLActive@GMX.Net wrote:
Hi all,
I must be quick, before the system locks down again.
I recalled this problem was reported last month -- thread "File system becomes read-only", to which you contributed. No solution was posted to the list, no one mentioned anything about a bug report, and I cannot find any bug report summaries that look even remotely close to the problem.
Yes, you're right. I have no solution yet, and the problem occurs on three very different systems. I mentioned them in that theread as well. It is becoming alarming now.
It seems that since I installed OpenSUSE 10.2 and used ext3 FS, I get system Lockdowns with the File System going Read Only suddenly. At bootup the ext3 rollback of journals seem to be doing something, even if the shut down was done normally.
There seems to be a correlation to high disk access, which occurs when either Evolution, KMail (Kontact) or Gimp loads and saves files on a default ext3 OpenSUES 10.2 root system, with a reiserfs partition mounted on /home/<user>/Data/Data1 and/or a xfs on /home/<user>/Data/Data2, where the data is. Can using different FS's in one system cause such problems?
How can I find out what causes it?
I tend to doubt that the specific filesystem(s) in use have anything at all to do with this, but the high disk access probably does. There is a thread on Dell about problems with the MegaRAID sas driver (module name megasas) -- http://lists.us.dell.com/pipermail/linux-poweredge/2007-March/029974.html -- but you have not given enough information for anyone to know if this is relevant to your problem. Grep /var/log/messages for "megasas".
As mentioned in that thread also, I have no megasys. I use two IDE based systems and one x86_64 SATA system.
One writer in that thread (on Dell) writes "the problem is that the Linux kernel's SCSI layer insists on a single timeout for all SCSI requests, and doesn't tolerate high variances in command completion times. If any single command times out, it resets the whole bus, even if there is still significant activity." This suggests that the problem is more widespread than just a RAID issue. This is that writer's message -- http://lists.us.dell.com/pipermail/linux-poweredge/2007-March/029982.html -- and it contains a suggestion that may be of use to you.
that is why I think Carl previously has something about mixing FS partitions on a single drive. I have, however, noticed the problem even on completely separate drives (completely partitioned with only one FS type like reiserfs V3), but with different FS's mounted under a newly installed default OpenSUSE 10.2 ext3 System. This system only had one IDE channel (7-8 years old), with the default (all packages installed except Laptop apps) OpenSUSE 10.2 with ext3. I then mounted only the old reiserfs v3 drive as /home/<user>/Data/Data1. This system did not even want to mount the drive at bootup. I then repartitioned and formated it as ext3 and it worked again, so no HW problems. The curious thing is that I have been doing this mixing of FS's a while with OpenSUSE 10.1 and Novell's purchased boxed SUSE 10,1 without these problems.
You'll need to give us a lot more information about your system hardware (including the modules that are loaded for hard drive i/o),.
Here some HW details: 1. A 5 year old system that had win2K on it for 3 years and since then SuSE 9.3 and all the following. Here the problem occur with OpenSUSE 10.2. It has an ASUS mobo with ATI Radion graphic card. 2. A 2 year old system only had SuSE 10.0 that had the problem and now has WinXP without any problems. It's a Gigabyte mobo with ATI Radion graphic card. I noticed that intensive file access by Evolution caused a systrem lockup many times. 3. The latest 1 year old system showed the problem mainly with SUSE 10.0 and now with OpenSUSE 10.2. An identical system has SuSE 10.1, where the problem has till now not occured. It is a Gigabyte GA-K8N-SLi mobo with nVidia GeForce 7600 GS. The difference between the lockups of the SUSE 10.0 and OpenSUSE 10.2 is that with 10.0 it did not allow any access to the system at all; a complete lockdown - dead - only reset got it unlocked. The OpenSUSE 10.2 reports RO FS problems by all applications. The system can be rebooted or shut down normally. plus
information from /var/log/messages about what is happening when the filesystem goes RO
I noticed on two different systems this sort of messages in /var/logs/messages: Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: error=0x04 { DriveStatusError } Jun 2 22:15:03 kakalapap kernel: ide: failed opcode was: 0xef For now, I need stability. I will follow Carl's suggestion and get all partitions onto one FS type. I'm a little apprehensive to use ext3 or XFS. Need I be? Patrick seems happy with ext3. Not sure what Carl uses. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 LLLActive@GMX.Net wrote:
On Wed 20 June 2007 00:56, Darryl Gregorash wrote:
Hi all,
I must be quick, before the system locks down again. I recalled this problem was reported last month -- thread "File system becomes read-only", to which you contributed. No solution was posted to
On 06/19/2007 03:11 PM, LLLActive@GMX.Net wrote: the list, no one mentioned anything about a bug report, and I cannot find any bug report summaries that look even remotely close to the problem.
Yes, you're right. I have no solution yet, and the problem occurs on three very different systems. I mentioned them in that theread as well. It is becoming alarming now.
<snip>
You'll need to give us a lot more information about your system hardware (including the modules that are loaded for hard drive i/o),.
Here some HW details: 1. A 5 year old system that had win2K on it for 3 years and since then SuSE 9.3 and all the following. Here the problem occur with OpenSUSE 10.2. It has an ASUS mobo with ATI Radion graphic card. 2. A 2 year old system only had SuSE 10.0 that had the problem and now has WinXP without any problems. It's a Gigabyte mobo with ATI Radion graphic card. I noticed that intensive file access by Evolution caused a systrem lockup many times. 3. The latest 1 year old system showed the problem mainly with SUSE 10.0 and now with OpenSUSE 10.2. An identical system has SuSE 10.1, where the problem has till now not occured. It is a Gigabyte GA-K8N-SLi mobo with nVidia GeForce 7600 GS.
The difference between the lockups of the SUSE 10.0 and OpenSUSE 10.2 is that with 10.0 it did not allow any access to the system at all; a complete lockdown - dead - only reset got it unlocked. The OpenSUSE 10.2 reports RO FS problems by all applications. The system can be rebooted or shut down normally.
plus
information from /var/log/messages about what is happening when the filesystem goes RO
I noticed on two different systems this sort of messages in /var/logs/messages:
Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: error=0x04 { DriveStatusError } Jun 2 22:15:03 kakalapap kernel: ide: failed opcode was: 0xef
For now, I need stability. I will follow Carl's suggestion and get all partitions onto one FS type. I'm a little apprehensive to use ext3 or XFS. Need I be? Patrick seems happy with ext3. Not sure what Carl uses.
I have had an on and off experience of this particular issue... There seem to be three common elements for me... i) Before the problem kicks in one started experiencing network connections going into CLOSE_WAIT states... ii) famd starts becoming a CPU hog. Files start being reported as been use when not. iii) commands and applications start reporting segment faults. The last two are detectable if one is lucky enough to have an active terminal session available. These are probably symptoms of something at a lower level doing something it should not, but because of the I/O lockdown it is nearly impossible to monitor system status to identify what is at fault. Oddly these conditions were most recently associated with a situation with a couple of server end IMAP mail folders hitting about 7000 messages (laziness on my part). Thunderbird started timing out. Restarting IMAP server clearing problem for a short while but after two or three restarts system became unstable with above symptoms. Even after full reboot was only a matter of time before whole thing locked up. Since keeping folder sizes under control (i.e. under 7000 or so) this has not happened (looking for forest to touch :-)), which also proves nothing BTW (except possibly it is a failure of something to recover from an error condition). The problem first occurred soon after upgrading to 10.2 and seemed to be initially associated with a dud tape drive. After disconnecting tape drive I got stability for about 2-3 weeks before problem returned. Some other things suggested to me that it may have not been the tape drive initially at fault, and at some point I intend to conduct some tests on the drive to determine whether it is really faulty (I dont have a suitable test config at moment). The problem occurs only on a dual opteron box with 64bit OS, not on my 32bit machine. There is no SCSI on box... BTW This is a rieserFS only box. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGeOYDasN0sSnLmgIRAs12AKDa5XzS4nImxlP5CVBGyduIMItFUwCgvsdT sbBYlv1n0ooPF6+/rSrKL70= =RcZc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed 20 June 2007 10:32, G T Smith wrote:
LLLActive@GMX.Net wrote:
On Wed 20 June 2007 00:56, Darryl Gregorash wrote:
On 06/19/2007 03:11 PM, LLLActive@GMX.Net wrote:
Hi all,
I must be quick, before the system locks down again.
I recalled this problem was reported last month -- thread "File system becomes read-only", to which you contributed. No solution was posted to the list, no one mentioned anything about a bug report, and I cannot find any bug report summaries that look even remotely close to the problem.
Yes, you're right. I have no solution yet, and the problem occurs on three very different systems. I mentioned them in that theread as well. It is becoming alarming now.
<snip>
You'll need to give us a lot more information about your system hardware (including the modules that are loaded for hard drive i/o),.
Here some HW details: 1. A 5 year old system that had win2K on it for 3 years and since then SuSE 9.3 and all the following. Here the problem occur with OpenSUSE 10.2. It has an ASUS mobo with ATI Radion graphic card. 2. A 2 year old system only had SuSE 10.0 that had the problem and now has WinXP without any problems. It's a Gigabyte mobo with ATI Radion graphic card. I noticed that intensive file access by Evolution caused a systrem lockup many times. 3. The latest 1 year old system showed the problem mainly with SUSE 10.0 and now with OpenSUSE 10.2. An identical system has SuSE 10.1, where the problem has till now not occured. It is a Gigabyte GA-K8N-SLi mobo with nVidia GeForce 7600 GS.
The difference between the lockups of the SUSE 10.0 and OpenSUSE 10.2 is that with 10.0 it did not allow any access to the system at all; a complete lockdown - dead - only reset got it unlocked. The OpenSUSE 10.2 reports RO FS problems by all applications. The system can be rebooted or shut down normally.
plus
information from /var/log/messages about what is happening when the filesystem goes RO
I noticed on two different systems this sort of messages in /var/logs/messages:
Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: error=0x04 { DriveStatusError } Jun 2 22:15:03 kakalapap kernel: ide: failed opcode was: 0xef
For now, I need stability. I will follow Carl's suggestion and get all partitions onto one FS type. I'm a little apprehensive to use ext3 or XFS. Need I be? Patrick seems happy with ext3. Not sure what Carl uses.
I have had an on and off experience of this particular issue...
There seem to be three common elements for me...
i) Before the problem kicks in one started experiencing network connections going into CLOSE_WAIT states...
ii) famd starts becoming a CPU hog. Files start being reported as been use when not.
iii) commands and applications start reporting segment faults.
The last two are detectable if one is lucky enough to have an active terminal session available. These are probably symptoms of something at a lower level doing something it should not, but because of the I/O lockdown it is nearly impossible to monitor system status to identify what is at fault.
Oddly these conditions were most recently associated with a situation with a couple of server end IMAP mail folders hitting about 7000 messages (laziness on my part). Thunderbird started timing out. Restarting IMAP server clearing problem for a short while but after two or three restarts system became unstable with above symptoms. Even after full reboot was only a matter of time before whole thing locked up.
Since keeping folder sizes under control (i.e. under 7000 or so) this has not happened (looking for forest to touch :-)), which also proves nothing BTW (except possibly it is a failure of something to recover
from an error condition).
The problem first occurred soon after upgrading to 10.2 and seemed to be initially associated with a dud tape drive. After disconnecting tape drive I got stability for about 2-3 weeks before problem returned.
Some other things suggested to me that it may have not been the tape drive initially at fault, and at some point I intend to conduct some tests on the drive to determine whether it is really faulty (I dont have a suitable test config at moment).
The problem occurs only on a dual opteron box with 64bit OS, not on my 32bit machine. There is no SCSI on box...
With me it is both x86_64 AMD and a normal AMD Duron XP2000
BTW This is a rieserFS only box.
Wow, it is all a bit much, no commonality, BUT as you mention the IMAP and with me also a number of POP accounts have a lot of mails (also this list btw) in it with around 6K-7K mails in total. It seemed to be linked to both Evolution and Kontact. I actually switched to Kontact because I suspected Evolution's activity to cause the problem. I will close down both and see what hapens. My problem is that I work a lot with Gimp and large *.JPG & *.PNG files to edit (100 MB), and it seemed to also cause the problem once I loaded a file to edit. Then Gimp immediately reports it cannot save temp files and will not budge an inch further ... In a terminal window I notice the system jumps to /var/logs and a tail -n30 /var/logs/messages report a RO File System. Closing the tail, a message reporting the ro fs problem comes constantly to the command prompt. Is the problem associated with file system access, e.g. many or large files which causes high activity? Luckely my Servers are on SLES 10 and SLES 9, one DRBD cluster running (don't laugh) on two SATA RAID 5 Novell SUSE 10.0 flawlessly since 2005.01.01. What else than reducing disk access can be done? :-( Al -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 LLLActive@GMX.Net wrote:
On Wed 20 June 2007 10:32, G T Smith wrote:
LLLActive@GMX.Net wrote:
On Wed 20 June 2007 00:56, Darryl Gregorash wrote:
<really big snip>
Oddly these conditions were most recently associated with a situation with a couple of server end IMAP mail folders hitting about 7000 messages (laziness on my part). Thunderbird started timing out. Restarting IMAP server clearing problem for a short while but after two or three restarts system became unstable with above symptoms. Even after full reboot was only a matter of time before whole thing locked up.
Since keeping folder sizes under control (i.e. under 7000 or so) this has not happened (looking for forest to touch :-)), which also proves nothing BTW (except possibly it is a failure of something to recover
<snip>
With me it is both x86_64 AMD and a normal AMD Duron XP2000
BTW This is a rieserFS only box.
Wow, it is all a bit much, no commonality, BUT as you mention the IMAP and with me also a number of POP accounts have a lot of mails (also this list btw) in it with around 6K-7K mails in total. It seemed to be linked to both Evolution and Kontact. I actually switched to Kontact because I suspected Evolution's activity to cause the problem. I will close down both and see what hapens.
My problem is that I work a lot with Gimp and large *.JPG & *.PNG files to edit (100 MB), and it seemed to also cause the problem once I loaded a file to edit. Then Gimp immediately reports it cannot save temp files and will not budge an inch further ... In a terminal window I notice the system jumps to /var/logs and a tail -n30 /var/logs/messages report a RO File System. Closing the tail, a message reporting the ro fs problem comes constantly to the command prompt.
The box concerned acts as a storage, print, e-mail server (configured to drag all my mail into one location) and a few other things (some a little experimental). It is usually driven from my laptop... This is the kind of I/O related symptom I am seeing, a kind of degenerative loss of access to part then all of the file system. However, I am not working with large files, and file activity is modest most of the time.
Is the problem associated with file system access, e.g. many or large files which causes high activity? Luckely my Servers are on SLES 10 and SLES 9, one DRBD cluster running (don't laugh) on two SATA RAID 5 Novell SUSE 10.0 flawlessly since 2005.01.01.
What else than reducing disk access can be done?
I dunno, I am not entirely certain whether disk access issues are a symptom or the problem. From my experience as a programmer my gut feel is that this is a failure to handle an error condition which is causing some memory corruption. However, in the absence of any error conditions in the logs, and my lack of knowledge of kernel internals I have no idea where to look further. The annoying thing about this kind of problem is that it could be caused by something completely unrelated to the processes reporting the symptoms. I am not really in a position to set the thing up to generate large amounts of non-specific debug info...
:-(
me to..
Al
- -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGeQZNasN0sSnLmgIRAr4LAKCRLY9rDUbukhrY9NOLlxCrCHs0ZQCeMEDq QZbj20nBOGtBqh+AEFBm5iU= =kKDV -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On 06/20/2007 04:01 AM, LLLActive@GMX.Net wrote:
<snip>
Is the problem associated with file system access, e.g. many or large files which causes high activity? Luckely my Servers are on SLES 10 and SLES 9, one DRBD cluster running (don't laugh) on two SATA RAID 5 Novell SUSE 10.0 flawlessly since 2005.01.01.
What else than reducing disk access can be done?
If you would actually read the entire thread at Dell instead of discounting it because it starts out talking about RAID, you might find an answer. The problem appears to be due to intensive disk activity, with a large number of simultaneous access requests. The suggested workaround is to increase the timeout. I believe that has to be done per drive, but see the thread. -- Hypocrisy is the homage vice pays to virtue. -- François de La Rochefoucauld -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed, 2007-06-20 at 09:05 +0200, LLLActive@GMX.Net wrote:
Here some HW details: 1. A 5 year old system that had win2K on it for 3 years and since then SuSE 9.3 and all the following. Here the problem occur with OpenSUSE
5 year old system = possible harddrive beyond its life expectancy.
10.2. It has an ASUS mobo with ATI Radion graphic card. 2. A 2 year old system only had SuSE 10.0 that had the problem and now has WinXP without any problems. It's a Gigabyte mobo with ATI Radion graphic card. I noticed that intensive file access by Evolution caused a systrem lockup many times. 3. The latest 1 year old system showed the problem mainly with SUSE 10.0 and now with OpenSUSE 10.2. An identical system has SuSE 10.1, where the problem has till now not occured. It is a Gigabyte GA-K8N-SLi mobo with nVidia GeForce 7600 GS.
Even newer systems come with a one year warranty on IDE harddrives. I've seen new drives fail after only a couple of months of use includinf SCSI drives which generally have a longer life expectancy.
The difference between the lockups of the SUSE 10.0 and OpenSUSE 10.2 is that with 10.0 it did not allow any access to the system at all; a complete lockdown - dead - only reset got it unlocked. The OpenSUSE 10.2 reports RO FS problems by all applications. The system can be rebooted or shut down normally.
plus
information from /var/log/messages about what is happening when the filesystem goes RO
I noticed on two different systems this sort of messages in /var/logs/messages:
Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: error=0x04 { DriveStatusError } Jun 2 22:15:03 kakalapap kernel: ide: failed opcode was: 0xef
I only see these errors in relation to my DVD/CD drive (hda). Could this possibly relate to your CD drive? If not I would suspect a bad cable. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wed 20 June 2007 13:59, Kenneth Schneider wrote:
On Wed, 2007-06-20 at 09:05 +0200, LLLActive@GMX.Net wrote:
Here some HW details: 1. A 5 year old system that had win2K on it for 3 years and since then SuSE 9.3 and all the following. Here the problem occur with OpenSUSE
5 year old system = possible harddrive beyond its life expectancy.
10.2. It has an ASUS mobo with ATI Radion graphic card. 2. A 2 year old system only had SuSE 10.0 that had the problem and now has WinXP without any problems. It's a Gigabyte mobo with ATI Radion graphic card. I noticed that intensive file access by Evolution caused a systrem lockup many times. 3. The latest 1 year old system showed the problem mainly with SUSE 10.0 and now with OpenSUSE 10.2. An identical system has SuSE 10.1, where the problem has till now not occured. It is a Gigabyte GA-K8N-SLi mobo with nVidia GeForce 7600 GS.
Even newer systems come with a one year warranty on IDE harddrives. I've seen new drives fail after only a couple of months of use includinf SCSI drives which generally have a longer life expectancy.
The difference between the lockups of the SUSE 10.0 and OpenSUSE 10.2 is that with 10.0 it did not allow any access to the system at all; a complete lockdown - dead - only reset got it unlocked. The OpenSUSE 10.2 reports RO FS problems by all applications. The system can be rebooted or shut down normally.
plus
information from /var/log/messages about what is happening when the filesystem goes RO
I noticed on two different systems this sort of messages in /var/logs/messages:
Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } Jun 2 22:15:03 kakalapap kernel: hda: task_no_data_intr: error=0x04 { DriveStatusError } Jun 2 22:15:03 kakalapap kernel: ide: failed opcode was: 0xef
I only see these errors in relation to my DVD/CD drive (hda). Could this possibly relate to your CD drive? If not I would suspect a bad cable.
I followed Carl's suggestion and changed the file systems to ext3. It seems that the use of different file systems on the same drive with different partitions is the problem. Since I changed all partitins to ext3, the problem did not come up anymore. High disk access does not seem to bother it now. I have also reduced the number of e-mails in the mail boxes as Graham suggests, but only one account is IMAP. This was done after the FS's were changed, and it caused a lot of disk access when deleting the mails. Everything, including the large *.jpg, *.tiff & other graphics files in Gimp could be processed with high disk access also. So all seem to point into the direction Carl described thus: On Tue 19 June 2007 23:47, Carl Hartung wrote:
On Tue June 19 2007 17:11, LLLActive@GMX.Net wrote: <snip>
... Can using different FS's in one system cause such problems?
Theoretically, no, but in actual fact there are circumstances where conflicts *can* arise.
In my case... with this specific chipset and corresponding kernel IDE controller module... cache buffering is enabled or disabled on a per drive basis. Running disparate filesystem types in adjacent partitions on the same drive (i.e. reiserfs + ext3) triggered errors comparable to those you're experiencing now.
I ultimately coaxed those errors away permanently by standardizing my installations to using only one journaling filesystem type per drive.
hth & regards,
Carl
:-) Al -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Wednesday 20 June 2007 00:56:00 Darryl Gregorash wrote:
You'll need to give us a lot more information about your system hardware (including the modules that are loaded for hard drive i/o), plus information from /var/log/messages about what is happening when the filesystem goes RO.
OK. I will give as much as I can. The mail is therefore a bit long ... I have solved the problem partly by keeping to one FS per drive, as suggested by Carl Hartung. Thanx Carl. On Tuesday 19 June 2007 23:47:43 Carl Hartung wrote:
On Tue June 19 2007 17:11, LLLActive@GMX.Net wrote: <snip>
... Can using different FS's in one system cause such problems?
Theoretically, no, but in actual fact there are circumstances where conflicts *can* arise.
In my case... with this specific chipset and corresponding kernel IDE controller module... cache buffering is enabled or disabled on a per drive basis. Running disparate filesystem types in adjacent partitions on the same drive (i.e. reiserfs + ext3) triggered errors comparable to those you're experiencing now.
I ultimately coaxed those errors away permanently by standardizing my installations to using only one journaling filesystem type per drive.
The system is much more stable. ################################ Last night. however, it happened again !! I put my mobile phone on the USB port. I left the mobile phone on the USB on to charge the batteries, thinking nothing of it. Only when I did some access to it the files disappeared after the listing. The USB was detached automatically from the USB HUB. Again thinking nothing of it, I attached it directly to a USB port om the MOBO. I then wanted to install from a dvd mounted as /dev/hdd, and did a lot of disk access, the system went RO FS again. I went to bed .... On Wednesday 20 June 2007 00:56:00 Darryl Gregorash wrote:
I tend to doubt that the specific filesystem(s) in use have anything at all to do with this, but the high disk access probably does. There is a thread on Dell about problems with the MegaRAID sas driver (module name megasas) -- http://lists.us.dell.com/pipermail/linux-poweredge/2007-March/029974.html -- but you have not given enough information for anyone to know if this is relevant to your problem. Grep /var/log/messages for "megasas".
sudo more /var/log/messages | grep "megasys" reports nothing Looking at the logs again afterwards this morning, I noticed these SCSI part /dev/sda1. sico@sico:~> sudo more /var/log/messages | grep "sda" Jun 30 22:43:28 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:43:28 sico kernel: sda: Write Protect is off Jun 30 22:43:28 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:43:28 sico kernel: sda: assuming drive cache: write through Jun 30 22:43:28 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:43:28 sico kernel: sda: Write Protect is off Jun 30 22:43:28 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:43:28 sico kernel: sda: assuming drive cache: write through Jun 30 22:43:28 sico kernel: sda: sda1 Jun 30 22:43:28 sico kernel: sd 0:0:0:0: Attached scsi removable disk sda Jun 30 22:43:30 sico hald: mounted /dev/sda1 on behalf of uid 1000 Jun 30 22:47:57 sico kernel: sda: Current: sense key: No Sense ... (repeated many times) ... Jun 30 22:47:58 sico kernel: end_request: I/O error, dev sda, sector 14464 Jun 30 22:47:59 sico hald: unmounted /dev/sda1 from '/media/disk' on behalf of uid 0 Jun 30 22:47:59 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:47:59 sico kernel: sda: Write Protect is off Jun 30 22:47:59 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:47:59 sico kernel: sda: assuming drive cache: write through Jun 30 22:47:59 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:47:59 sico kernel: sda: Write Protect is off Jun 30 22:47:59 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:47:59 sico kernel: sda: assuming drive cache: write through Jun 30 22:47:59 sico kernel: sda: sda1 Jun 30 22:47:59 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:47:59 sico kernel: sda: Write Protect is off Jun 30 22:47:59 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:47:59 sico kernel: sda: assuming drive cache: write through Jun 30 22:47:59 sico kernel: sda: sda1 Jun 30 22:48:01 sico hald: mounted /dev/sda1 on behalf of uid 1000 Jun 30 22:48:26 sico kernel: sda: Current: sense key: No Sense Jun 30 22:48:27 sico kernel: end_request: I/O error, dev sda, sector 9152 Jun 30 22:48:27 sico kernel: end_request: I/O error, dev sda, sector 9152 ... (repeated many times) ... Jun 30 22:48:27 sico kernel: end_request: I/O error, dev sda, sector 19328 Jun 30 22:48:27 sico hald: unmounted /dev/sda1 from '/media/disk' on behalf of uid 0 Jun 30 22:48:29 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:48:29 sico kernel: sda: Write Protect is off Jun 30 22:48:29 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:48:29 sico kernel: sda: assuming drive cache: write through Jun 30 22:48:29 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:48:29 sico kernel: sda: Write Protect is off Jun 30 22:48:29 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:48:29 sico kernel: sda: assuming drive cache: write through Jun 30 22:48:29 sico kernel: sda: sda1 Jun 30 22:48:31 sico hald: mounted /dev/sda1 on behalf of uid 1000 Jun 30 22:48:37 sico kernel: sda: Current: sense key: No Sense Jun 30 22:48:37 sico kernel: end_request: I/O error, dev sda, sector 40320 ... (repeated many times) ... Jun 30 22:48:38 sico kernel: end_request: I/O error, dev sda, sector 46144 Jun 30 22:48:38 sico hald: unmounted /dev/sda1 from '/media/disk' on behalf of uid 0 Jun 30 22:48:40 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:48:40 sico kernel: sda: Write Protect is off Jun 30 22:48:40 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:48:40 sico kernel: sda: assuming drive cache: write through Jun 30 22:48:40 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:48:40 sico kernel: sda: Write Protect is off Jun 30 22:48:40 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:48:40 sico kernel: sda: assuming drive cache: write through Jun 30 22:48:40 sico kernel: sda: sda1 Jun 30 22:48:41 sico hald: mounted /dev/sda1 on behalf of uid 1000 Jun 30 22:48:45 sico kernel: sda: Current: sense key: No Sense Jun 30 22:48:45 sico kernel: end_request: I/O error, dev sda, sector 41280 Jun 30 22:48:45 sico kernel: end_request: I/O error, dev sda, sector 41280 ... (repeated many times) ... Jun 30 22:48:46 sico kernel: end_request: I/O error, dev sda, sector 73344 Jun 30 22:48:47 sico hald: unmounted /dev/sda1 from '/media/disk' on behalf of uid 0 Jun 30 22:48:47 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:48:47 sico kernel: sda: Write Protect is off Jun 30 22:48:47 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:48:47 sico kernel: sda: assuming drive cache: write through Jun 30 22:48:47 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:48:47 sico kernel: sda: Write Protect is off Jun 30 22:48:47 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:48:47 sico kernel: sda: assuming drive cache: write through Jun 30 22:48:47 sico kernel: sda: sda1 Jun 30 22:48:48 sico hald: mounted /dev/sda1 on behalf of uid 1000 Jun 30 22:48:50 sico kernel: sda: Current: sense key: No Sense Jun 30 22:48:50 sico kernel: end_request: I/O error, dev sda, sector 1985 Jun 30 22:48:50 sico kernel: end_request: I/O error, dev sda, sector 41088 ... (repeated many times) ... Jun 30 22:48:51 sico kernel: end_request: I/O error, dev sda, sector 50624 Jun 30 22:48:51 sico hald: unmounted /dev/sda1 from '/media/disk' on behalf of uid 0 Jun 30 22:48:53 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:48:53 sico kernel: sda: Write Protect is off Jun 30 22:48:53 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:48:53 sico kernel: sda: assuming drive cache: write through Jun 30 22:48:53 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jun 30 22:48:53 sico kernel: sda: Write Protect is off Jun 30 22:48:53 sico kernel: sda: Mode Sense: 00 6a 00 00 Jun 30 22:48:53 sico kernel: sda: assuming drive cache: write through Jun 30 22:48:53 sico kernel: sda: sda1 Jun 30 22:48:54 sico hald: mounted /dev/sda1 on behalf of uid 1000 Jun 30 22:48:59 sico kernel: sda: Current: sense key: No Sense Jun 30 22:48:59 sico kernel: end_request: I/O error, dev sda, sector 41088 ... (repeated many times) ...
One writer in that thread (on Dell) writes "the problem is that the Linux kernel's SCSI layer insists on a single timeout for all SCSI requests, and doesn't tolerate high variances in command completion times. If any single command times out, it resets the whole bus, even if there is still significant activity." This suggests that the problem is more widespread than just a RAID issue. This is that writer's message -- http://lists.us.dell.com/pipermail/linux-poweredge/2007-March/029982.html -- and it contains a suggestion that may be of use to you.
I found the mail of Joe Malicki (http://lists.us.dell.com/pipermail/linux-poweredge/2007-March/029982.html) about this topic and changed the SCSI timeout: sico@sico:~> more /sys/block/sda/device/timeout 60 sico@sico:~> sudo echo 120 > /sys/block/sda/device/timeout bash: /sys/block/sda/device/timeout: Permission denied sico@sico:~> su - Password: sico:~ # echo 120 > /sys/block/sda/device/timeout Current state: ... Jul 1 14:47:35 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jul 1 14:47:35 sico kernel: sda: Write Protect is off Jul 1 14:47:35 sico kernel: sda: Mode Sense: 00 6a 00 00 Jul 1 14:47:35 sico kernel: sda: assuming drive cache: write through Jul 1 14:47:35 sico kernel: SCSI device sda: 3903488 512-byte hdwr sectors (1999 MB) Jul 1 14:47:35 sico kernel: sda: Write Protect is off Jul 1 14:47:35 sico kernel: sda: Mode Sense: 00 6a 00 00 Jul 1 14:47:35 sico kernel: sda: assuming drive cache: write through Jul 1 14:47:35 sico kernel: sda: sda1 Jul 1 14:47:51 sico hald: mounted /dev/sda1 on behalf of uid 1000 The lines: Jun 30 22:48:59 sico kernel: sda: Current: sense key: No Sense Jun 30 22:48:59 sico kernel: end_request: I/O error, dev sda, sector 41088 ... (repeated many times) ... do not seem to come anymore after some extensive disk access as before. ################################ I am not sure what to make of these RO comments in the last lines in messages. Can it be that it just reports that the DVD is RO?: Jul 1 18:18:29 sico sudo: sico : TTY=pts/1 ; PWD=/home/sico ; USER=root ; COMMAND=/bin/more /var/log/messages Jul 1 18:20:29 sico kernel: ISO 9660 Extensions: Microsoft Joliet Level 3 Jul 1 18:20:29 sico kernel: ISO 9660 Extensions: RRIP_1991A Jul 1 18:20:29 sico hald: mounted /dev/hdd on behalf of uid 1000 Jul 1 18:21:53 sico gconfd (sico-5635): GConf server is not in use, shutting down. Jul 1 18:21:53 sico gconfd (sico-5635): Exiting Jul 1 18:26:43 sico gconfd (sico-18750): starting (version 2.14.0), pid 18750 user 'sico' Jul 1 18:26:43 sico gconfd (sico-18750): Resolved address "xml:readonly:/etc/opt/gnome/gconf/gconf.xml.mandatory" to a read-only configuration source at position 0 Jul 1 18:26:43 sico gconfd (sico-18750): Resolved address "xml:readwrite:/home/sico/.gconf" to a writable configuration source at position 1 Jul 1 18:26:43 sico gconfd (sico-18750): Resolved address "xml:readonly:/etc/opt/gnome/gconf/gconf.xml.defaults" to a read-only configuration source at position 2 Jul 1 18:26:43 sico gconfd (sico-18750): Resolved address "xml:readonly:/etc/opt/gnome/gconf/gconf.xml.schemas" to a read-only configuration source at position 3 Jul 1 18:27:13 sico gconfd (sico-18750): GConf server is not in use, shutting down. ################################ Is it normal for USB to use the SCSI layer? Can the SCSI layer be avoided? Can it be changed to IDE like /dev/hde? :-) Al -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (8)
-
Carl Hartung
-
Carlos E. R.
-
Darryl Gregorash
-
G T Smith
-
jfweber@gilweber.com
-
Kenneth Schneider
-
LLLActive@GMX.Net
-
Patrick Shanahan