home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.os.linux.mint      Looks pretty on the outside, thats it!      30,566 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 30,028 of 30,566   
   Paul to Computer Nerd Kev   
   Re: LM file transfer/copy issues   
   25 Dec 25 01:27:27   
   
   XPost: aus.computers   
   From: nospam@needed.invalid   
      
   On Wed, 12/24/2025 4:28 PM, Computer Nerd Kev wrote:   
   > In aus.computers Paul  wrote:   
   >> On Wed, 12/24/2025 1:41 AM, Computer Nerd Kev wrote:   
   >>> In aus.computers Axel  wrote:   
   >>>> or in a nutshell.. the question now is why did it write to that drive   
   >>>> and not others? is the size of the drive or it's software/technology   
   >>>> relevant?   
   >>>   
   >>> Maybe that drive (or the NTFS driver) is just too slow for whatever   
   >>> signal issue you have with the rack to be triggered.   
   >>>   
   >>> I'm not sure if they still do it on new HDDs, but maybe there's a   
   >>> jumper setting on the other drives to limit the speed?   
   >>> https://en.wikipedia.org/wiki/SATA#SATA_1.5_Gbit/s_and_SATA_3_Gbit/s   
   >>   
   >> No guarantees, but maybe an   
   >>   
   >>    lsusb   
   >>   
   >> and check the detection on the rack, would give   
   >> some idea of the controller being used.   
   >   
   > He said "swapped the cable to another motherboard (MB) SATA port"   
   > so that must mean the rack uses SATA connection/s to the   
   > motherboard, not USB. In that case "lsusb" won't show it. If the   
   > rack is poorly designed or an old model then maybe it introduces   
   > too much signal noise for operating at higer data speeds. Or maybe   
   > there's a bad connection, but he also said he replaced the rack.   
   >   
      
   OK. Maybe we're making progress then.   
      
   It seemed that Southbridge ports were made "kinda ESATA compatible"   
   by having their launch amplitude and receive sensitivity designed   
   so the port could be used with ESATA.   
      
   However, ESATA only seemed to be validated for SATA II, and not SATA III.   
   The higher rate may be too much for it. I've never seem a reference   
   to the SATAIO standards people, claiming ESATA was ready for SATA III   
   (due to cable length).   
      
   With Linux at least, you don't need to wait for the domain validation   
   kind of logic to catch up with things.   
      
   https://www.reddit.com/r/archlinux/comments/hegh2r/how_doshould_   
   _limit_sata_link_speed_on_a_hard/   
      
       https://serverfault.com/questions/400338/how-to-reduce-the-s   
   ta-link-speed-of-drive-in-centos/400347#400347   
      
   A kernel boot line of   
      
       libata.force=3.0        # Gear-down all ports   
      
       libata.force=1:3.0G \___ Makes the boot option port specific   
       libata.force=2:3.0G /   
      
   In /etc/default/grub where it says "quiet splash", that is where you could add   
   that clause.   
      
   So at least, now I know there is a lever, and it's a matter of studying   
   the particular hardware (what chip is being used), to see if it is   
   going to work, or seeing what "port numbering issue" might be at play.   
      
   Some boards have a six port Southbridge plus an add-on chip driving two ESATA   
   ports.   
   In which case, I don't know how the ports will get numbered or identified.   
   The above URLs go into that at bit.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca