From trs80 at ucc.gu.uwa.edu.au Fri Sep 5 18:12:58 2014 From: trs80 at ucc.gu.uwa.edu.au (James Andrewartha) Date: Fri, 5 Sep 2014 18:12:58 +0800 (WST) Subject: [tech] /away is full Message-ID: I have freed up a bit of space with tune2fs, but really we need to clean up home directories; /backups/restored/space/away/home/du-20140727 has some likely candidates. mylah:/backups/restored/space/away/home# df -h /backups Filesystem Size Used Avail Use% Mounted on /dev/mapper/sanspace-backups 1.9T 1.8T 0 100% /backups mylah:/backups/restored/space/away/home# tune2fs -m1 /dev/mapper/sanspace-backups tune2fs 1.42.5 (29-Jul-2012) Setting reserved blocks percentage to 1% (4924620 blocks) mylah:/backups/restored/space/away/home# df -h /backups Filesystem Size Used Avail Use% Mounted on /dev/mapper/sanspace-backups 1.9T 1.8T 29G 99% /backups -- # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | [ "There's nobody getting rich writing ]| -- Collect and hide your | [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / From matt at ucc.asn.au Fri Sep 5 20:38:11 2014 From: matt at ucc.asn.au (Matt Johnston) Date: Fri, 5 Sep 2014 20:38:11 +0800 Subject: [tech] DegradedArray event on /dev/md/1:motsugo Message-ID: <20140905123811.GK8675@ucc.gu.uwa.edu.au> Does motsugo's disk need replacing, or is something wrong with cables etc? smartctl can't see it I don't think. It's the system raid VG 'reliable'. Matt ----- Forwarded message from mdadm monitoring ----- Date: Fri, 5 Sep 2014 06:27:38 +0800 (WST) From: mdadm monitoring To: root at ucc.gu.uwa.edu.au Subject: DegradedArray event on /dev/md/1:motsugo This is an automatically generated mail message from mdadm running on motsugo A DegradedArray event had been detected on md device /dev/md/1. Faithfully yours, etc. P.S. The /proc/mdstat file currently contains the following: Personalities : [raid1] [raid6] [raid5] [raid4] md0 : active raid6 sdc1[0] sdg1[4] sdf1[3] sde1[2] sdd1[1] 5860535808 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU] md1 : active raid1 sda1[2](F) sdb1[1] 117211608 blocks super 1.2 [2/1] [_U] unused devices: ----- End forwarded message ----- From bob at ucc.gu.uwa.edu.au Fri Sep 5 22:24:14 2014 From: bob at ucc.gu.uwa.edu.au (Andrew Adamson) Date: Fri, 5 Sep 2014 22:24:14 +0800 (WST) Subject: [tech] DegradedArray event on /dev/md/1:motsugo In-Reply-To: <20140905123811.GK8675@ucc.gu.uwa.edu.au> References: <20140905123811.GK8675@ucc.gu.uwa.edu.au> Message-ID: Nick and I pulled the busted OCZ Vertex 2 disk out tonight - it does get recognised when plugged back in but `smartctl -a /dev/sdi' is showing lots of old-age/pre-fail errors (output txt attached). Is anyone free this weekend to go and get another of the 128G Samsungs that we've been buying lately? We've only got the one system disk at the moment so it's rather urgent. On a side note, this is the disk that we were worried about dying at the start of this year (and caused us to add another disk) - adding the extra disk seems to have paid off :-) Andrew Adamson bob at ucc.asn.au |"If you can't beat them, join them, and then beat them." | | ---Peter's Laws | On Fri, 5 Sep 2014, Matt Johnston wrote: > Does motsugo's disk need replacing, or is something wrong > with cables etc? smartctl can't see it I don't think. It's > the system raid VG 'reliable'. > > Matt > > ----- Forwarded message from mdadm monitoring ----- > > Date: Fri, 5 Sep 2014 06:27:38 +0800 (WST) > From: mdadm monitoring > To: root at ucc.gu.uwa.edu.au > Subject: DegradedArray event on /dev/md/1:motsugo > > This is an automatically generated mail message from mdadm > running on motsugo > > A DegradedArray event had been detected on md device /dev/md/1. > > Faithfully yours, etc. > > P.S. The /proc/mdstat file currently contains the following: > > Personalities : [raid1] [raid6] [raid5] [raid4] > md0 : active raid6 sdc1[0] sdg1[4] sdf1[3] sde1[2] sdd1[1] > 5860535808 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU] > > md1 : active raid1 sda1[2](F) sdb1[1] > 117211608 blocks super 1.2 [2/1] [_U] > > unused devices: > > ----- End forwarded message ----- > _______________________________________________ > List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech > > Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/bob%40ucc.gu.uwa.edu.au > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: motsugo-sda-OCZ.20140905.txt Url: http://lists.ucc.gu.uwa.edu.au/pipermail/tech/attachments/20140905/8547c5e4/attachment.txt From bob at ucc.gu.uwa.edu.au Fri Sep 5 22:26:05 2014 From: bob at ucc.gu.uwa.edu.au (Andrew Adamson) Date: Fri, 5 Sep 2014 22:26:05 +0800 (WST) Subject: [tech] /away is full In-Reply-To: References: Message-ID: OKAY OKAY, I'm moving my big stuff onto pomona....60G or so should be freed up. Andrew Adamson bob at ucc.asn.au |"If you can't beat them, join them, and then beat them." | | ---Peter's Laws | On Fri, 5 Sep 2014, James Andrewartha wrote: > I have freed up a bit of space with tune2fs, but really we need to clean > up home directories; /backups/restored/space/away/home/du-20140727 has > some likely candidates. > > mylah:/backups/restored/space/away/home# df -h /backups > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/sanspace-backups 1.9T 1.8T 0 100% /backups > mylah:/backups/restored/space/away/home# tune2fs -m1 /dev/mapper/sanspace-backups > tune2fs 1.42.5 (29-Jul-2012) > Setting reserved blocks percentage to 1% (4924620 blocks) > mylah:/backups/restored/space/away/home# df -h /backups > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/sanspace-backups 1.9T 1.8T 29G 99% /backups > > -- > # TRS-80 trs80(a)ucc.gu.uwa.edu.au #/ "Otherwise Bub here will do \ > # UCC Wheel Member http://trs80.ucc.asn.au/ #| what squirrels do best | > [ "There's nobody getting rich writing ]| -- Collect and hide your | > [ software that I know of" -- Bill Gates, 1980 ]\ nuts." -- Acid Reflux #231 / > _______________________________________________ > List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech > > Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/bob%40ucc.gu.uwa.edu.au > From mjpomery at ucc.asn.au Fri Sep 5 23:01:46 2014 From: mjpomery at ucc.asn.au (Mitchell Pomery) Date: Fri, 5 Sep 2014 23:01:46 +0800 (WST) Subject: [tech] The Snack Machine Message-ID: So I had a look at why the snack machine was broken, and it was due to the fact that one of the pairs between merlo and it was broken. I have since fixed that and everything is working fine. TL;DR; Get your MiFare Mitch From matt at ucc.asn.au Sat Sep 6 14:13:16 2014 From: matt at ucc.asn.au (Matt Johnston) Date: Sat, 6 Sep 2014 14:13:16 +0800 Subject: [tech] DegradedArray event on /dev/md/1:motsugo In-Reply-To: References: <20140905123811.GK8675@ucc.gu.uwa.edu.au> Message-ID: <20140906061316.GL8675@ucc.gu.uwa.edu.au> I got a 128GB Samsung 850 Pro, $145 from PLE, MSY had no stock. It's on the floor of the machineroom, I forgot my key. I'll take coke credit. Matt On Fri, Sep 05, 2014 at 10:24:14PM +0800, Andrew Adamson wrote: > Nick and I pulled the busted OCZ Vertex 2 disk out tonight - it does get > recognised when plugged back in but `smartctl -a /dev/sdi' is showing lots > of old-age/pre-fail errors (output txt attached). > > Is anyone free this weekend to go and get another of the 128G Samsungs > that we've been buying lately? We've only got the one system disk at the > moment so it's rather urgent. > > On a side note, this is the disk that we were worried about dying at the > start of this year (and caused us to add another disk) - adding the extra > disk seems to have paid off :-) > > Andrew Adamson > bob at ucc.asn.au > > |"If you can't beat them, join them, and then beat them." | > | ---Peter's Laws | > > On Fri, 5 Sep 2014, Matt Johnston wrote: > > > Does motsugo's disk need replacing, or is something wrong > > with cables etc? smartctl can't see it I don't think. It's > > the system raid VG 'reliable'. > > > > Matt > > > > ----- Forwarded message from mdadm monitoring ----- > > > > Date: Fri, 5 Sep 2014 06:27:38 +0800 (WST) > > From: mdadm monitoring > > To: root at ucc.gu.uwa.edu.au > > Subject: DegradedArray event on /dev/md/1:motsugo > > > > This is an automatically generated mail message from mdadm > > running on motsugo > > > > A DegradedArray event had been detected on md device /dev/md/1. > > > > Faithfully yours, etc. > > > > P.S. The /proc/mdstat file currently contains the following: > > > > Personalities : [raid1] [raid6] [raid5] [raid4] > > md0 : active raid6 sdc1[0] sdg1[4] sdf1[3] sde1[2] sdd1[1] > > 5860535808 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU] > > > > md1 : active raid1 sda1[2](F) sdb1[1] > > 117211608 blocks super 1.2 [2/1] [_U] > > > > unused devices: > > > > ----- End forwarded message ----- > > _______________________________________________ > > List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech > > > > Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/bob%40ucc.gu.uwa.edu.au > > > root at motsugo:/var/log# tail -f /var/log/kern.log > Sep 5 22:06:23 motsugo kernel: [16759166.111673] ata1: SError: { PHYRdyChg DevExch } > Sep 5 22:06:23 motsugo kernel: [16759166.111705] ata1: hard resetting link > Sep 5 22:06:23 motsugo kernel: [16759166.831245] ata1: SATA link down (SStatus 0 SControl 300) > Sep 5 22:06:23 motsugo kernel: [16759166.831256] ata1: EH complete > Sep 5 22:06:23 motsugo kernel: [16759166.831269] ata1.00: detaching (SCSI 0:0:0:0) > Sep 5 22:06:23 motsugo kernel: [16759166.834140] sd 0:0:0:0: [sda] Synchronizing SCSI cache > Sep 5 22:06:23 motsugo kernel: [16759166.834182] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK > Sep 5 22:06:23 motsugo kernel: [16759166.834187] sd 0:0:0:0: [sda] Stopping disk > Sep 5 22:06:23 motsugo kernel: [16759166.834200] sd 0:0:0:0: [sda] START_STOP FAILED > Sep 5 22:06:23 motsugo kernel: [16759166.834202] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK > > > > Sep 5 22:08:54 motsugo kernel: [16759317.250330] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen > Sep 5 22:08:54 motsugo kernel: [16759317.250377] ata1: irq_stat 0x00400040, connection status changed > Sep 5 22:08:54 motsugo kernel: [16759317.250406] ata1: SError: { RecovComm PHYRdyChg CommWake DevExch } > Sep 5 22:08:54 motsugo kernel: [16759317.250441] ata1: hard resetting link > Sep 5 22:08:55 motsugo kernel: [16759317.969984] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > Sep 5 22:08:55 motsugo kernel: [16759318.560019] ata1.00: ATA-8: OCZ-VERTEX2, 1.27, max UDMA/133 > Sep 5 22:08:55 motsugo kernel: [16759318.560024] ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32), AA > Sep 5 22:08:55 motsugo kernel: [16759318.631611] ata1.00: configured for UDMA/133 > Sep 5 22:08:55 motsugo kernel: [16759318.631621] ata1: EH complete > Sep 5 22:08:55 motsugo kernel: [16759318.631752] scsi 0:0:0:0: Direct-Access ATA OCZ-VERTEX2 1.27 PQ: 0 ANSI: 5 > Sep 5 22:08:55 motsugo kernel: [16759318.632304] sd 0:0:0:0: Attached scsi generic sg0 type 0 > Sep 5 22:08:55 motsugo kernel: [16759318.632307] sd 0:0:0:0: [sdi] 234441648 512-byte logical blocks: (120 GB/111 GiB) > Sep 5 22:08:55 motsugo kernel: [16759318.632395] sd 0:0:0:0: [sdi] Write Protect is off > Sep 5 22:08:55 motsugo kernel: [16759318.632399] sd 0:0:0:0: [sdi] Mode Sense: 00 3a 00 00 > Sep 5 22:08:55 motsugo kernel: [16759318.632430] sd 0:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA > Sep 5 22:08:55 motsugo kernel: [16759318.633184] sdi: sdi1 > Sep 5 22:08:55 motsugo kernel: [16759318.633491] sd 0:0:0:0: [sdi] Attached SCSI disk > > > ^C > root at motsugo:/var/log# fdisk -l /dev/sdi > > Disk /dev/sdi: 120.0 GB, 120034123776 bytes > 81 heads, 63 sectors/track, 45941 cylinders, total 234441648 sectors > Units = sectors of 1 * 512 = 512 bytes > Sector size (logical/physical): 512 bytes / 512 bytes > I/O size (minimum/optimal): 512 bytes / 512 bytes > Disk identifier: 0x000291a1 > > Device Boot Start End Blocks Id System > /dev/sdi1 * 2048 234441647 117219800 fd Linux raid autodetect > root at motsugo:/var/log# smartctl -a /dev/sdi > smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > === START OF INFORMATION SECTION === > Model Family: SandForce Driven SSDs > Device Model: OCZ-VERTEX2 > Serial Number: OCZ-10O78Z46ES6Z8177 > LU WWN Device Id: 5 e83a97 fead4d449 > Firmware Version: 1.27 > User Capacity: 120,034,123,776 bytes [120 GB] > Sector Size: 512 bytes logical/physical > Device is: In smartctl database [for details use: -P show] > ATA Version is: 8 > ATA Standard is: ATA-8-ACS revision 6 > Local Time is: Fri Sep 5 22:09:48 2014 WST > SMART support is: Available - device has SMART capability. > SMART support is: Enabled > > === START OF READ SMART DATA SECTION === > SMART overall-health self-assessment test result: PASSED > > General SMART Values: > Offline data collection status: (0x00) Offline data collection activity > was never started. > Auto Offline Data Collection: Disabled. > Self-test execution status: ( 0) The previous self-test routine completed > without error or no self-test has ever > been run. > Total time to complete Offline > data collection: ( 0) seconds. > Offline data collection > capabilities: (0x7f) SMART execute Offline immediate. > Auto Offline data collection on/off support. > Abort Offline collection upon new > command. > Offline surface scan supported. > Self-test supported. > Conveyance Self-test supported. > Selective Self-test supported. > SMART capabilities: (0x0003) Saves SMART data before entering > power-saving mode. > Supports SMART auto save timer. > Error logging capability: (0x01) Error logging supported. > General Purpose Logging supported. > Short self-test routine > recommended polling time: ( 1) minutes. > Extended self-test routine > recommended polling time: ( 48) minutes. > Conveyance self-test routine > recommended polling time: ( 2) minutes. > SCT capabilities: (0x003d) SCT Status supported. > SCT Error Recovery Control supported. > SCT Feature Control supported. > SCT Data Table supported. > > SMART Attributes Data Structure revision number: 10 > Vendor Specific SMART Attributes with Thresholds: > ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE > 1 Raw_Read_Error_Rate 0x000f 120 120 050 Pre-fail Always - 0/0 > 5 Retired_Block_Count 0x0033 100 100 003 Pre-fail Always - 0 > 9 Power_On_Hours_and_Msec 0x0032 100 100 000 Old_age Always - 31432h+05m+50.310s > 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 45 > 171 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0 > 172 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0 > 174 Unexpect_Power_Loss_Ct 0x0030 000 000 000 Old_age Offline - 28 > 177 Wear_Range_Delta 0x0000 000 000 000 Old_age Offline - 0 > 181 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0 > 182 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0 > 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 > 194 Temperature_Celsius 0x0022 030 129 000 Old_age Always - 30 (Min/Max 30/30) > 195 ECC_Uncorr_Error_Count 0x001c 120 120 000 Old_age Offline - 0/0 > 196 Reallocated_Event_Count 0x0033 100 100 000 Pre-fail Always - 0 > 231 SSD_Life_Left 0x0013 100 100 010 Pre-fail Always - 0 > 233 SandForce_Internal 0x0000 000 000 000 Old_age Offline - 3392 > 234 SandForce_Internal 0x0032 000 000 000 Old_age Always - 3456 > 241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 3456 > 242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 13184 > > SMART Error Log not supported > SMART Self-test Log not supported > SMART Selective self-test log data structure revision number 1 > SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS > 1 0 0 Not_testing > 2 0 0 Not_testing > 3 0 0 Not_testing > 4 0 0 Not_testing > 5 0 0 Not_testing > Selective self-test flags (0x0): > After scanning selected spans, do NOT read-scan remainder of disk. > If Selective self-test is pending on power-up, resume after 0 minute delay. From mjpomery at ucc.asn.au Sat Sep 6 14:23:01 2014 From: mjpomery at ucc.asn.au (Mitchell Pomery) Date: Sat, 6 Sep 2014 14:23:01 +0800 (WST) Subject: [tech] DegradedArray event on /dev/md/1:motsugo In-Reply-To: <20140906061316.GL8675@ucc.gu.uwa.edu.au> References: <20140905123811.GK8675@ucc.gu.uwa.edu.au> <20140906061316.GL8675@ucc.gu.uwa.edu.au> Message-ID: If someone can help me work out which SSD needs to be replaced, I can sort that out in about an hour. Mitch On Sat, 6 Sep 2014, Matt Johnston wrote: > I got a 128GB Samsung 850 Pro, $145 from PLE, MSY had no stock. > It's on the floor of the machineroom, I forgot my key. > I'll take coke credit. > > Matt > > On Fri, Sep 05, 2014 at 10:24:14PM +0800, Andrew Adamson wrote: >> Nick and I pulled the busted OCZ Vertex 2 disk out tonight - it does get >> recognised when plugged back in but `smartctl -a /dev/sdi' is showing lots >> of old-age/pre-fail errors (output txt attached). >> >> Is anyone free this weekend to go and get another of the 128G Samsungs >> that we've been buying lately? We've only got the one system disk at the >> moment so it's rather urgent. >> >> On a side note, this is the disk that we were worried about dying at the >> start of this year (and caused us to add another disk) - adding the extra >> disk seems to have paid off :-) >> >> Andrew Adamson >> bob at ucc.asn.au >> >> |"If you can't beat them, join them, and then beat them." | >> | ---Peter's Laws | >> >> On Fri, 5 Sep 2014, Matt Johnston wrote: >> >>> Does motsugo's disk need replacing, or is something wrong >>> with cables etc? smartctl can't see it I don't think. It's >>> the system raid VG 'reliable'. >>> >>> Matt >>> >>> ----- Forwarded message from mdadm monitoring ----- >>> >>> Date: Fri, 5 Sep 2014 06:27:38 +0800 (WST) >>> From: mdadm monitoring >>> To: root at ucc.gu.uwa.edu.au >>> Subject: DegradedArray event on /dev/md/1:motsugo >>> >>> This is an automatically generated mail message from mdadm >>> running on motsugo >>> >>> A DegradedArray event had been detected on md device /dev/md/1. >>> >>> Faithfully yours, etc. >>> >>> P.S. The /proc/mdstat file currently contains the following: >>> >>> Personalities : [raid1] [raid6] [raid5] [raid4] >>> md0 : active raid6 sdc1[0] sdg1[4] sdf1[3] sde1[2] sdd1[1] >>> 5860535808 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU] >>> >>> md1 : active raid1 sda1[2](F) sdb1[1] >>> 117211608 blocks super 1.2 [2/1] [_U] >>> >>> unused devices: >>> >>> ----- End forwarded message ----- >>> _______________________________________________ >>> List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech >>> >>> Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/bob%40ucc.gu.uwa.edu.au >>> > >> root at motsugo:/var/log# tail -f /var/log/kern.log >> Sep 5 22:06:23 motsugo kernel: [16759166.111673] ata1: SError: { PHYRdyChg DevExch } >> Sep 5 22:06:23 motsugo kernel: [16759166.111705] ata1: hard resetting link >> Sep 5 22:06:23 motsugo kernel: [16759166.831245] ata1: SATA link down (SStatus 0 SControl 300) >> Sep 5 22:06:23 motsugo kernel: [16759166.831256] ata1: EH complete >> Sep 5 22:06:23 motsugo kernel: [16759166.831269] ata1.00: detaching (SCSI 0:0:0:0) >> Sep 5 22:06:23 motsugo kernel: [16759166.834140] sd 0:0:0:0: [sda] Synchronizing SCSI cache >> Sep 5 22:06:23 motsugo kernel: [16759166.834182] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK >> Sep 5 22:06:23 motsugo kernel: [16759166.834187] sd 0:0:0:0: [sda] Stopping disk >> Sep 5 22:06:23 motsugo kernel: [16759166.834200] sd 0:0:0:0: [sda] START_STOP FAILED >> Sep 5 22:06:23 motsugo kernel: [16759166.834202] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK >> >> >> >> Sep 5 22:08:54 motsugo kernel: [16759317.250330] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen >> Sep 5 22:08:54 motsugo kernel: [16759317.250377] ata1: irq_stat 0x00400040, connection status changed >> Sep 5 22:08:54 motsugo kernel: [16759317.250406] ata1: SError: { RecovComm PHYRdyChg CommWake DevExch } >> Sep 5 22:08:54 motsugo kernel: [16759317.250441] ata1: hard resetting link >> Sep 5 22:08:55 motsugo kernel: [16759317.969984] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >> Sep 5 22:08:55 motsugo kernel: [16759318.560019] ata1.00: ATA-8: OCZ-VERTEX2, 1.27, max UDMA/133 >> Sep 5 22:08:55 motsugo kernel: [16759318.560024] ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32), AA >> Sep 5 22:08:55 motsugo kernel: [16759318.631611] ata1.00: configured for UDMA/133 >> Sep 5 22:08:55 motsugo kernel: [16759318.631621] ata1: EH complete >> Sep 5 22:08:55 motsugo kernel: [16759318.631752] scsi 0:0:0:0: Direct-Access ATA OCZ-VERTEX2 1.27 PQ: 0 ANSI: 5 >> Sep 5 22:08:55 motsugo kernel: [16759318.632304] sd 0:0:0:0: Attached scsi generic sg0 type 0 >> Sep 5 22:08:55 motsugo kernel: [16759318.632307] sd 0:0:0:0: [sdi] 234441648 512-byte logical blocks: (120 GB/111 GiB) >> Sep 5 22:08:55 motsugo kernel: [16759318.632395] sd 0:0:0:0: [sdi] Write Protect is off >> Sep 5 22:08:55 motsugo kernel: [16759318.632399] sd 0:0:0:0: [sdi] Mode Sense: 00 3a 00 00 >> Sep 5 22:08:55 motsugo kernel: [16759318.632430] sd 0:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA >> Sep 5 22:08:55 motsugo kernel: [16759318.633184] sdi: sdi1 >> Sep 5 22:08:55 motsugo kernel: [16759318.633491] sd 0:0:0:0: [sdi] Attached SCSI disk >> >> >> ^C >> root at motsugo:/var/log# fdisk -l /dev/sdi >> >> Disk /dev/sdi: 120.0 GB, 120034123776 bytes >> 81 heads, 63 sectors/track, 45941 cylinders, total 234441648 sectors >> Units = sectors of 1 * 512 = 512 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> Disk identifier: 0x000291a1 >> >> Device Boot Start End Blocks Id System >> /dev/sdi1 * 2048 234441647 117219800 fd Linux raid autodetect >> root at motsugo:/var/log# smartctl -a /dev/sdi >> smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build) >> Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net >> >> === START OF INFORMATION SECTION === >> Model Family: SandForce Driven SSDs >> Device Model: OCZ-VERTEX2 >> Serial Number: OCZ-10O78Z46ES6Z8177 >> LU WWN Device Id: 5 e83a97 fead4d449 >> Firmware Version: 1.27 >> User Capacity: 120,034,123,776 bytes [120 GB] >> Sector Size: 512 bytes logical/physical >> Device is: In smartctl database [for details use: -P show] >> ATA Version is: 8 >> ATA Standard is: ATA-8-ACS revision 6 >> Local Time is: Fri Sep 5 22:09:48 2014 WST >> SMART support is: Available - device has SMART capability. >> SMART support is: Enabled >> >> === START OF READ SMART DATA SECTION === >> SMART overall-health self-assessment test result: PASSED >> >> General SMART Values: >> Offline data collection status: (0x00) Offline data collection activity >> was never started. >> Auto Offline Data Collection: Disabled. >> Self-test execution status: ( 0) The previous self-test routine completed >> without error or no self-test has ever >> been run. >> Total time to complete Offline >> data collection: ( 0) seconds. >> Offline data collection >> capabilities: (0x7f) SMART execute Offline immediate. >> Auto Offline data collection on/off support. >> Abort Offline collection upon new >> command. >> Offline surface scan supported. >> Self-test supported. >> Conveyance Self-test supported. >> Selective Self-test supported. >> SMART capabilities: (0x0003) Saves SMART data before entering >> power-saving mode. >> Supports SMART auto save timer. >> Error logging capability: (0x01) Error logging supported. >> General Purpose Logging supported. >> Short self-test routine >> recommended polling time: ( 1) minutes. >> Extended self-test routine >> recommended polling time: ( 48) minutes. >> Conveyance self-test routine >> recommended polling time: ( 2) minutes. >> SCT capabilities: (0x003d) SCT Status supported. >> SCT Error Recovery Control supported. >> SCT Feature Control supported. >> SCT Data Table supported. >> >> SMART Attributes Data Structure revision number: 10 >> Vendor Specific SMART Attributes with Thresholds: >> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE >> 1 Raw_Read_Error_Rate 0x000f 120 120 050 Pre-fail Always - 0/0 >> 5 Retired_Block_Count 0x0033 100 100 003 Pre-fail Always - 0 >> 9 Power_On_Hours_and_Msec 0x0032 100 100 000 Old_age Always - 31432h+05m+50.310s >> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 45 >> 171 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0 >> 172 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0 >> 174 Unexpect_Power_Loss_Ct 0x0030 000 000 000 Old_age Offline - 28 >> 177 Wear_Range_Delta 0x0000 000 000 000 Old_age Offline - 0 >> 181 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0 >> 182 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0 >> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 >> 194 Temperature_Celsius 0x0022 030 129 000 Old_age Always - 30 (Min/Max 30/30) >> 195 ECC_Uncorr_Error_Count 0x001c 120 120 000 Old_age Offline - 0/0 >> 196 Reallocated_Event_Count 0x0033 100 100 000 Pre-fail Always - 0 >> 231 SSD_Life_Left 0x0013 100 100 010 Pre-fail Always - 0 >> 233 SandForce_Internal 0x0000 000 000 000 Old_age Offline - 3392 >> 234 SandForce_Internal 0x0032 000 000 000 Old_age Always - 3456 >> 241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 3456 >> 242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 13184 >> >> SMART Error Log not supported >> SMART Self-test Log not supported >> SMART Selective self-test log data structure revision number 1 >> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS >> 1 0 0 Not_testing >> 2 0 0 Not_testing >> 3 0 0 Not_testing >> 4 0 0 Not_testing >> 5 0 0 Not_testing >> Selective self-test flags (0x0): >> After scanning selected spans, do NOT read-scan remainder of disk. >> If Selective self-test is pending on power-up, resume after 0 minute delay. > > _______________________________________________ > List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech > > Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/bobgeorge33%40ucc.asn.au > From sulix at ucc.gu.uwa.edu.au Sat Sep 6 16:54:09 2014 From: sulix at ucc.gu.uwa.edu.au (David Gow) Date: Sat, 6 Sep 2014 16:54:09 +0800 (WST) Subject: [tech] DegradedArray event on /dev/md/1:motsugo In-Reply-To: References: <20140905123811.GK8675@ucc.gu.uwa.edu.au> <20140906061316.GL8675@ucc.gu.uwa.edu.au> Message-ID: So [BG3] and I set up the new SSD: all seems to be working fine. Linux is calling it sdi, because it can, so the system raid is: /dev/md1: sdb1, sdi1 Everything's been synced over, and there have been no obvious problems. Grub was installed with the usual "grub-install /dev/sdi". It should work, but we haven't rebooted motsugo to check. The next person to reboot it may be in for some excitement if grub is feeling grumpy. ? [SLX] On Sat, 6 Sep 2014, Mitchell Pomery wrote: > If someone can help me work out which SSD needs to be replaced, I can sort > that out in about an hour. > > Mitch > > On Sat, 6 Sep 2014, Matt Johnston wrote: > >> I got a 128GB Samsung 850 Pro, $145 from PLE, MSY had no stock. >> It's on the floor of the machineroom, I forgot my key. >> I'll take coke credit. >> >> Matt >> >> On Fri, Sep 05, 2014 at 10:24:14PM +0800, Andrew Adamson wrote: >>> Nick and I pulled the busted OCZ Vertex 2 disk out tonight - it does get >>> recognised when plugged back in but `smartctl -a /dev/sdi' is showing lots >>> of old-age/pre-fail errors (output txt attached). >>> >>> Is anyone free this weekend to go and get another of the 128G Samsungs >>> that we've been buying lately? We've only got the one system disk at the >>> moment so it's rather urgent. >>> >>> On a side note, this is the disk that we were worried about dying at the >>> start of this year (and caused us to add another disk) - adding the extra >>> disk seems to have paid off :-) >>> >>> Andrew Adamson >>> bob at ucc.asn.au >>> >>> |"If you can't beat them, join them, and then beat them." | >>> | ---Peter's Laws | >>> >>> On Fri, 5 Sep 2014, Matt Johnston wrote: >>> >>>> Does motsugo's disk need replacing, or is something wrong >>>> with cables etc? smartctl can't see it I don't think. It's >>>> the system raid VG 'reliable'. >>>> >>>> Matt >>>> >>>> ----- Forwarded message from mdadm monitoring ----- >>>> >>>> Date: Fri, 5 Sep 2014 06:27:38 +0800 (WST) >>>> From: mdadm monitoring >>>> To: root at ucc.gu.uwa.edu.au >>>> Subject: DegradedArray event on /dev/md/1:motsugo >>>> >>>> This is an automatically generated mail message from mdadm >>>> running on motsugo >>>> >>>> A DegradedArray event had been detected on md device /dev/md/1. >>>> >>>> Faithfully yours, etc. >>>> >>>> P.S. The /proc/mdstat file currently contains the following: >>>> >>>> Personalities : [raid1] [raid6] [raid5] [raid4] >>>> md0 : active raid6 sdc1[0] sdg1[4] sdf1[3] sde1[2] sdd1[1] >>>> 5860535808 blocks super 1.2 level 6, 512k chunk, algorithm 2 [5/5] [UUUUU] >>>> >>>> md1 : active raid1 sda1[2](F) sdb1[1] >>>> 117211608 blocks super 1.2 [2/1] [_U] >>>> >>>> unused devices: >>>> >>>> ----- End forwarded message ----- >>>> _______________________________________________ >>>> List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech >>>> >>>> Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/bob%40ucc.gu.uwa.edu.au >>>> >> >>> root at motsugo:/var/log# tail -f /var/log/kern.log >>> Sep 5 22:06:23 motsugo kernel: [16759166.111673] ata1: SError: { PHYRdyChg DevExch } >>> Sep 5 22:06:23 motsugo kernel: [16759166.111705] ata1: hard resetting link >>> Sep 5 22:06:23 motsugo kernel: [16759166.831245] ata1: SATA link down (SStatus 0 SControl 300) >>> Sep 5 22:06:23 motsugo kernel: [16759166.831256] ata1: EH complete >>> Sep 5 22:06:23 motsugo kernel: [16759166.831269] ata1.00: detaching (SCSI 0:0:0:0) >>> Sep 5 22:06:23 motsugo kernel: [16759166.834140] sd 0:0:0:0: [sda] Synchronizing SCSI cache >>> Sep 5 22:06:23 motsugo kernel: [16759166.834182] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK >>> Sep 5 22:06:23 motsugo kernel: [16759166.834187] sd 0:0:0:0: [sda] Stopping disk >>> Sep 5 22:06:23 motsugo kernel: [16759166.834200] sd 0:0:0:0: [sda] START_STOP FAILED >>> Sep 5 22:06:23 motsugo kernel: [16759166.834202] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK >>> >>> >>> >>> Sep 5 22:08:54 motsugo kernel: [16759317.250330] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen >>> Sep 5 22:08:54 motsugo kernel: [16759317.250377] ata1: irq_stat 0x00400040, connection status changed >>> Sep 5 22:08:54 motsugo kernel: [16759317.250406] ata1: SError: { RecovComm PHYRdyChg CommWake DevExch } >>> Sep 5 22:08:54 motsugo kernel: [16759317.250441] ata1: hard resetting link >>> Sep 5 22:08:55 motsugo kernel: [16759317.969984] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >>> Sep 5 22:08:55 motsugo kernel: [16759318.560019] ata1.00: ATA-8: OCZ-VERTEX2, 1.27, max UDMA/133 >>> Sep 5 22:08:55 motsugo kernel: [16759318.560024] ata1.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32), AA >>> Sep 5 22:08:55 motsugo kernel: [16759318.631611] ata1.00: configured for UDMA/133 >>> Sep 5 22:08:55 motsugo kernel: [16759318.631621] ata1: EH complete >>> Sep 5 22:08:55 motsugo kernel: [16759318.631752] scsi 0:0:0:0: Direct-Access ATA OCZ-VERTEX2 1.27 PQ: 0 ANSI: 5 >>> Sep 5 22:08:55 motsugo kernel: [16759318.632304] sd 0:0:0:0: Attached scsi generic sg0 type 0 >>> Sep 5 22:08:55 motsugo kernel: [16759318.632307] sd 0:0:0:0: [sdi] 234441648 512-byte logical blocks: (120 GB/111 GiB) >>> Sep 5 22:08:55 motsugo kernel: [16759318.632395] sd 0:0:0:0: [sdi] Write Protect is off >>> Sep 5 22:08:55 motsugo kernel: [16759318.632399] sd 0:0:0:0: [sdi] Mode Sense: 00 3a 00 00 >>> Sep 5 22:08:55 motsugo kernel: [16759318.632430] sd 0:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA >>> Sep 5 22:08:55 motsugo kernel: [16759318.633184] sdi: sdi1 >>> Sep 5 22:08:55 motsugo kernel: [16759318.633491] sd 0:0:0:0: [sdi] Attached SCSI disk >>> >>> >>> ^C >>> root at motsugo:/var/log# fdisk -l /dev/sdi >>> >>> Disk /dev/sdi: 120.0 GB, 120034123776 bytes >>> 81 heads, 63 sectors/track, 45941 cylinders, total 234441648 sectors >>> Units = sectors of 1 * 512 = 512 bytes >>> Sector size (logical/physical): 512 bytes / 512 bytes >>> I/O size (minimum/optimal): 512 bytes / 512 bytes >>> Disk identifier: 0x000291a1 >>> >>> Device Boot Start End Blocks Id System >>> /dev/sdi1 * 2048 234441647 117219800 fd Linux raid autodetect >>> root at motsugo:/var/log# smartctl -a /dev/sdi >>> smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build) >>> Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net >>> >>> === START OF INFORMATION SECTION === >>> Model Family: SandForce Driven SSDs >>> Device Model: OCZ-VERTEX2 >>> Serial Number: OCZ-10O78Z46ES6Z8177 >>> LU WWN Device Id: 5 e83a97 fead4d449 >>> Firmware Version: 1.27 >>> User Capacity: 120,034,123,776 bytes [120 GB] >>> Sector Size: 512 bytes logical/physical >>> Device is: In smartctl database [for details use: -P show] >>> ATA Version is: 8 >>> ATA Standard is: ATA-8-ACS revision 6 >>> Local Time is: Fri Sep 5 22:09:48 2014 WST >>> SMART support is: Available - device has SMART capability. >>> SMART support is: Enabled >>> >>> === START OF READ SMART DATA SECTION === >>> SMART overall-health self-assessment test result: PASSED >>> >>> General SMART Values: >>> Offline data collection status: (0x00) Offline data collection activity >>> was never started. >>> Auto Offline Data Collection: Disabled. >>> Self-test execution status: ( 0) The previous self-test routine completed >>> without error or no self-test has ever >>> been run. >>> Total time to complete Offline >>> data collection: ( 0) seconds. >>> Offline data collection >>> capabilities: (0x7f) SMART execute Offline immediate. >>> Auto Offline data collection on/off support. >>> Abort Offline collection upon new >>> command. >>> Offline surface scan supported. >>> Self-test supported. >>> Conveyance Self-test supported. >>> Selective Self-test supported. >>> SMART capabilities: (0x0003) Saves SMART data before entering >>> power-saving mode. >>> Supports SMART auto save timer. >>> Error logging capability: (0x01) Error logging supported. >>> General Purpose Logging supported. >>> Short self-test routine >>> recommended polling time: ( 1) minutes. >>> Extended self-test routine >>> recommended polling time: ( 48) minutes. >>> Conveyance self-test routine >>> recommended polling time: ( 2) minutes. >>> SCT capabilities: (0x003d) SCT Status supported. >>> SCT Error Recovery Control supported. >>> SCT Feature Control supported. >>> SCT Data Table supported. >>> >>> SMART Attributes Data Structure revision number: 10 >>> Vendor Specific SMART Attributes with Thresholds: >>> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE >>> 1 Raw_Read_Error_Rate 0x000f 120 120 050 Pre-fail Always - 0/0 >>> 5 Retired_Block_Count 0x0033 100 100 003 Pre-fail Always - 0 >>> 9 Power_On_Hours_and_Msec 0x0032 100 100 000 Old_age Always - 31432h+05m+50.310s >>> 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 45 >>> 171 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0 >>> 172 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0 >>> 174 Unexpect_Power_Loss_Ct 0x0030 000 000 000 Old_age Offline - 28 >>> 177 Wear_Range_Delta 0x0000 000 000 000 Old_age Offline - 0 >>> 181 Program_Fail_Count 0x0032 000 000 000 Old_age Always - 0 >>> 182 Erase_Fail_Count 0x0032 000 000 000 Old_age Always - 0 >>> 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 >>> 194 Temperature_Celsius 0x0022 030 129 000 Old_age Always - 30 (Min/Max 30/30) >>> 195 ECC_Uncorr_Error_Count 0x001c 120 120 000 Old_age Offline - 0/0 >>> 196 Reallocated_Event_Count 0x0033 100 100 000 Pre-fail Always - 0 >>> 231 SSD_Life_Left 0x0013 100 100 010 Pre-fail Always - 0 >>> 233 SandForce_Internal 0x0000 000 000 000 Old_age Offline - 3392 >>> 234 SandForce_Internal 0x0032 000 000 000 Old_age Always - 3456 >>> 241 Lifetime_Writes_GiB 0x0032 000 000 000 Old_age Always - 3456 >>> 242 Lifetime_Reads_GiB 0x0032 000 000 000 Old_age Always - 13184 >>> >>> SMART Error Log not supported >>> SMART Self-test Log not supported >>> SMART Selective self-test log data structure revision number 1 >>> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS >>> 1 0 0 Not_testing >>> 2 0 0 Not_testing >>> 3 0 0 Not_testing >>> 4 0 0 Not_testing >>> 5 0 0 Not_testing >>> Selective self-test flags (0x0): >>> After scanning selected spans, do NOT read-scan remainder of disk. >>> If Selective self-test is pending on power-up, resume after 0 minute delay. >> >> _______________________________________________ >> List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech >> >> Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/bobgeorge33%40ucc.asn.au >> > _______________________________________________ > List Archives: http://lists.ucc.gu.uwa.edu.au/pipermail/tech > > Unsubscribe here: http://lists.ucc.gu.uwa.edu.au/mailman/options/tech/sulix%40ucc.gu.uwa.edu.au > From matt at ucc.asn.au Tue Sep 9 21:14:31 2014 From: matt at ucc.asn.au (Matt Johnston) Date: Tue, 9 Sep 2014 21:14:31 +0800 Subject: [tech] Renewed *.ucc.asn.au Message-ID: <20140909131431.GM8675@ucc.gu.uwa.edu.au> I've renewed *.ucc.asn.au, Globalsign kindly give out free certificates for open source projects, Dropbear SSH is hosted at UCC. The new certificate is sha256 so won't work with Windows XP SP2. I've updated mooneye's postfix, mussel's apache, motsugo's dovecot. I think that's all? Matt From mjpomery at ucc.asn.au Mon Sep 15 12:54:31 2014 From: mjpomery at ucc.asn.au (Mitchell Pomery) Date: Mon, 15 Sep 2014 12:54:31 +0800 (WST) Subject: [tech] UCC's UPS Message-ID: The UPS is working again. FM has replaced the switch for the 15A White 12 circuit so we can use it again. The UPS is charging up and we will probably plug things into it tonight. Mitch From mjpomery at ucc.asn.au Mon Sep 15 13:01:42 2014 From: mjpomery at ucc.asn.au (Mitchell Pomery) Date: Mon, 15 Sep 2014 13:01:42 +0800 (WST) Subject: [tech] Napoli Message-ID: I jumped onto Napoli had a poke around and tried to figure out why it was crashing. I dusted it out inside (breaking open macs is a fun process) and dusted the fans. There wasn't much in there. I also checked and found an update, so I did that. Since then it's been working for the past two days. The problem looks fixed. I have disabled sleep on it to see if it will come back anytime soon. I will enable sleep again if it seems to be working fine. Side Note: Steam was derpy (would run at 1/100th of normal speed making it unusable) on it so I reinstalled that. Mitch [BG3] From mjpomery at ucc.asn.au Mon Sep 15 13:03:50 2014 From: mjpomery at ucc.asn.au (Mitchell Pomery) Date: Mon, 15 Sep 2014 13:03:50 +0800 (WST) Subject: [tech] Cichlid Message-ID: Cichlid is still having issues. I have done a fresh reinstall of it and the problem still persists. I've run hardware tests on it and they say everything is fine. I have a feeling that there is an issue with the graphics card, so if the problem persists I will swap it out and see if that fixes it. Mitch [BG3] From zanchey at ucc.gu.uwa.edu.au Mon Sep 15 13:10:42 2014 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Mon, 15 Sep 2014 13:10:42 +0800 (WST) Subject: [tech] UCC's UPS In-Reply-To: References: Message-ID: On Mon, 15 Sep 2014, Mitchell Pomery wrote: > The UPS is working again. FM has replaced the switch for the 15A White 12 > circuit so we can use it again. The UPS is charging up and we will > probably plug things into it tonight. And [BOB] got NUT/upsd working, so: zanchey at motsugo> upsc mainups at uccrouter ... battery.charge: 82 device.model: Liebert PSI 3000 FW:07 ups.status: OL CHRG I added it to the graphs in Cacti. You can login as `guest` with no password. https://secure.ucc.asn.au/cacti/graph_view.php?action=tree&tree_id=2&leaf_id=40 David Adam zanchey at ucc.gu.uwa.edu.au From zanchey at ucc.gu.uwa.edu.au Mon Sep 15 15:08:25 2014 From: zanchey at ucc.gu.uwa.edu.au (David Adam) Date: Mon, 15 Sep 2014 15:08:25 +0800 (WST) Subject: [tech] Molmol the slightly more fileserver In-Reply-To: References: <53D54303.4050005@ucc.asn.au> <53D514B5.9040207@ucc.asn.au> Message-ID: On Fri, 15 Aug 2014, David Adam wrote: > I'm not sure why the performance is so terrible on Debian. Obviously there > are lots of gaps in the matrix I haven't filled in (what's it like locally > on Debian+ZFS, what's performance on the stuff mounted on Mylah like), and > there's times when our network performance goes through the floor (down > from gigabit to 200 megabit or so) which I haven't worked out. Apparently NFS performance is much, much better in the next release of ZFSonLinux: https://github.com/zfsonlinux/zfs/issues/2599 (similar order of magnitude of slowdown over ZFS) [DAA] From maset at ucc.asn.au Wed Sep 17 04:20:43 2014 From: maset at ucc.asn.au (Anil Sharma) Date: Tue, 16 Sep 2014 22:20:43 +0200 Subject: [tech] Forgotten password Message-ID: Hey kids, I seem to have forgotten my UCC password. Is there a secure way I can get it reset, considering I am unable to physically come to the clubroom? Cheers, Anil. From nick at ucc.gu.uwa.edu.au Wed Sep 24 11:51:02 2014 From: nick at ucc.gu.uwa.edu.au (Nick Bannon) Date: Wed, 24 Sep 2014 11:51:02 +0800 Subject: [tech] ARM 2 revival project In-Reply-To: <54225FC2-D5FF-4D85-A0B6-2300812508B4@stairways.com.au> <48561F27-4CB1-478A-A56A-1848F84432B6@stairways.com.au> Message-ID: <20140924035102.GP24575@ucc.gu.uwa.edu.au> On Wed, Sep 24, 2014 at 11:23:32AM +0800, Peter N Lewis wrote: > On 24 Sep 2014, at 11:15, Nick Bannon wrote: > > Hi! Mind if I bounce this through to the tech at ucc.gu.uwa.edu.au list? > Not at all. Great! [BOB], [BG3] and I have started a little Monday night project... reviving the ARM2! Built starting in 1988 by [JPQ], we all had a peer into it last Friday after the 40th dinner. I'm not sure if it ever received a good name as such..? Maybe that's a TODO item. If basic hardware permits, I'm sure we can get it doing _something_ - it can't be harder than programming a Teensy, right? Lovely clean ARM26 assembler, I'm looking forward to our first ROM dumps. On Tue, Sep 23, 2014 at 09:59:18AM +0800, Peter N Lewis wrote: > From Marcus: > The ARM almost certainly it boots into a debugger talking on the serial port. There is floppy/scsi disk boot code in the ROM but I doubt it automatically triggers. > > I would guess that the command is "b " to trigger the boot. Either floppy/scsi or serial, no idea what options would be used to pick between them. > The debugger might have a help with the "?" command, but if it exists it would be cryptic. Thanks, [JMJ]! Many moons ago - you showed me it doing that very thing and there have been no hardware or ROM changes since then. With the possible exception of some connector wires falling off. [BOB], [BG3] and I dedusted it and tested out the power supply over the last two Monday evenings. It looks functional, there are definite clock and data signals flying around it, visible on the Tektronix DSO, some look cleaner than others. We haven't made it spit out any identifiable serial boot messages yet. There's a couple of potential serial ports, with a transmit line powered at -12-ish volts. I think: * one goes into the IOC; and * one goes into a pair of 1488/1489 RS-232 line (driver/receiver)s, which I can't see on the ARM.tiff circuit diagram. Do you know which one the boot monitor/debugger might be listening to? ( [PNL] replies: No idea. ) > Hmm... I wonder did we support the Kermit protocol for downloading the boot image? http://en.wikipedia.org/wiki/Kermit_(protocol) > > I do remember having to type a series of commands to ping the io ports to read/write disk blocks. We had a fancy FIFO chip that could grab the 512 byte block from the IO chips. And we had a fancy SCSI chip that handled all the scsi handshaking. And I had commands to read/write the FIFO to memory. > > I know we had a keyboard on it, did we have a mouse as well? Probably not. Looks like a AT keyboard? There's power on the right line, haven't had any responses back yet. > Is the scsi disk still installed? If it's there, I doubt it's functional. No, it's unplugged and possibly unterminated. > I guess you could power it on and see if there a video signal. Probably best to unplug the power supply from the board first to make sure the power supply comes up OK. > > Enjoy, > Peter. There's a likely looking video socket, a DE-9 female, I think. Not sure of the pinouts, we can probably work that out. How much code needs to run successfully before there's a video display? Should there be VSYNC and HSYNC signals running from power-on? ( [PNL] replies: Lots. And again, no idea. ... Good luck ) On Wed, Sep 24, 2014 at 09:40:42AM +0800, Peter N Lewis wrote: > Another comment from Marcus: > >If they really want it running then figuring out the custom PAL I made is going to be really interesting. Heh. Well, it's an excuse to finally upgrade our ROM burner. We've got a working one already, it's just plugged into a ISA bus on a 486 running DOS; with a floppy drive and no functional networking. Currrently choosing between a: * http://www.conitec.net/english/galep5.php * ...or a cheapo Chinese TL866A or similar. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig at rcpt.to | I lack the time to make it shorter." - Pascal From nick at ucc.gu.uwa.edu.au Wed Sep 24 13:18:06 2014 From: nick at ucc.gu.uwa.edu.au (Nick Bannon) Date: Wed, 24 Sep 2014 13:18:06 +0800 Subject: [tech] ARM 2 revival project In-Reply-To: <54224AA1.6060902@westnet.com.au> References: <20140924035102.GP24575@ucc.gu.uwa.edu.au> <54224AA1.6060902@westnet.com.au> Message-ID: <20140924051806.GA29447@ucc.gu.uwa.edu.au> On Wed, Sep 24, 2014 at 12:37:53PM +0800, Harry McNally wrote: > On 24/09/14 11:51, Nick Bannon wrote: > >Heh. Well, it's an excuse to finally upgrade our ROM burner. We've got > >a working one already, it's just plugged into a ISA bus on a 486 running > >DOS; with a floppy drive and no functional networking. > > Is that my programmer or is it only my eraser you have in Snack ? I > can't remember Just the eraser. It was on my mind: thanks, I've made an agenda item about getting one. USD$25 from: http://www.mcumall.com/comersus/store/comersus_viewItem.asp?idProduct=3204 or apparently a toothbrush steriliser works? > >Currently choosing between a: > > * http://www.conitec.net/english/galep5.php > > * ...or a cheapo Chinese TL866A or similar. > > Is the ARM2 board UVPROM a 2716 (2K x 8) or bigger ? Yep, a 2716 exactly. I think we had bigger ones for the snack machine - 27C256's? of which we had a bunch from [DAV]. > If you can programme one of these then no UV erasure needed so quick turnaround: > http://au.element14.com/atmel/at28c64b-15pu/ic-eeprom-parallel-64k-8k-x-8/dp/1095784 > It would be possible to make up a small adapter board with pins to > plug into a 2716, 2732, 2764 or whatever socket the board has. That would be nice... ATMEL - AT28C64B-15PU - IC, EEPROM PARALLEL 64K (8K x 8) So they're definitely _not_ pin compatible with a 2716 or a 27C256, right? but simple rearrangment can fix that? > A similar solution for snack if you want to hack further on that. > > I'm happy to help build this if you think it would be useful. > > All the best > Harry Lovely! Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig at rcpt.to | I lack the time to make it shorter." - Pascal From nick at ucc.gu.uwa.edu.au Wed Sep 24 15:31:14 2014 From: nick at ucc.gu.uwa.edu.au (Nick Bannon) Date: Wed, 24 Sep 2014 15:31:14 +0800 Subject: [tech] ARM 2 revival project In-Reply-To: <54226A92.3060106@westnet.com.au> References: <20140924035102.GP24575@ucc.gu.uwa.edu.au> <54224AA1.6060902@westnet.com.au> <20140924051806.GA29447@ucc.gu.uwa.edu.au> <54226A92.3060106@westnet.com.au> Message-ID: <20140924073113.GD29447@ucc.gu.uwa.edu.au> On Wed, Sep 24, 2014 at 02:54:10PM +0800, Harry McNally wrote: > On 24/09/14 13:18, Nick Bannon wrote: > >That would be nice... > >ATMEL - AT28C64B-15PU - IC, EEPROM PARALLEL 64K (8K x 8) > > > >So they're definitely _not_ pin compatible with a 2716 or a 27C256, > >right? but simple rearrangment can fix that? > > I believe so. I checked an SMD version for snack that required two > pins to be swapped. If a DIP like this is used then a small square > pad board that converts the pinout as needed. > > I'll have a look at the 2716 pinout. I didn't look at 2Kx8 DIP > EEPROM. They may be drop in parts! > > /me looks > > No 2Kx8 part (DIP or SMD) available so a rewire of 8Kx8. Using SMD > SO-28 or DIP. Quick pinout comparison. It's doable, similar two wire > swap I think. > I would suggest the SMD part on an SO-28 adapter (I have a Futurlec one). > > If UCC has a ZIF socket, I'd suggest you don't need the programmer > just yet. I can drop that ZIF on an arduino mega shield I have that > I built for Trent and set up an Arduino Mega to accept serial hex > (or S) file lines to it that just go straight onto the EEPROM. > Verify after write. Commands to dump back a hex or S file as well if > you wish. Worth a try. Probably don't want to steal the ZIF adaptor from the snack machine if we can avoid it. Mind you - we've been wanting a more futureproof universal device programmer all millenium so far, I've got emails talking about it in 2003. Not something we use every day, but even the USD$600 versions are cheap devices. The lack of one has stalled several projects including the snack machine; even though technically there are alternatives. > Does the ARM board have a ZIF socket ? If not, can one fit on the > board soldered into the 2716 socket if necessary (it might plug in > but they have fat pins). Can you email me the ARM circuit so I can > look at the 2716 connections ? Can you also send a photo of the 2716 > socket location to confirm we have the space to overhand a 28x0.3 > DIP daughter board ? The ARM ROMs are in simple dual wipe sockets. https://www.dropbox.com/s/ohaccocxy55d9u3/2014-09-12%2020.02.38.jpg [JJQ]'s circuit diagram, motsugo:~nick/ucc/ARM-quinn-circuit-diagram.jpg doesn't have that level of detail, but it shows all the buses. > So, to proceed, if you buy a couple of these: > http://au.element14.com/atmel/at28c64b-15su/eeprom-64kbit-parallel-soic-28/dp/2345619 > > and these (as needed for shield and ARM boards): > http://www.jaycar.com.au/productView.asp?ID=PI6483 > > We can crop pins on the ARM installed ZIF as long as the longer > socket can fit in the space. I've checked that this 28pin ZIF is as > wide as the 40pin one so it will take the DIP28 adapter board I > have. > > I can do the rest. Let me know if you want to proceed. Then just > drop me the parts or I can collect from UCC. > > We can build a snack one with the second part (or buy another spare) > if you want to use the same technique to hack on snack. > > All the best > Harry Sounds useful for faster programming turnarounds - especially if there's a similar EEPROM chip that has ICSP (In-Circuit Serial Programming) support. However, I think we do want our own programmer and UV eraser box as well. Nick. -- Nick Bannon | "I made this letter longer than usual because nick-sig at rcpt.to | I lack the time to make it shorter." - Pascal