jaeger changed the topic of #crux to: CRUX 3.7 | Homepage: https://crux.nu/ | Ports: https://crux.nu/portdb/ https://crux.ninja/portdb/ | Logs: https://libera.irclog.whitequark.org/crux/
ukky has quit [Quit: Installing OS]
ukky has joined #crux
ukky has quit [Quit: Rebooting]
ukky has joined #crux
ukky has quit [Quit: Rebooting]
ukky has joined #crux
<cruxbot> [opt.git/3.7]: prime-run: initial import
<cruxbot> [contrib.git/3.7]: bbswitch, bumblebee, primus: removed, use opt/prime-run instead
guido_rokepo has joined #crux
farkuhar has joined #crux
guido_rokepo has quit [Quit: guido_rokepo]
<ukky> SAS controller in my system, Intel C600 SAS, is not supported by kernel from install ISO. CRUX will be installed on SATA drive. My other drives attached to SAS controller will not be accessible during next upgrade. What users do in such cases to perform upgrade via ISO? Should I learn how to build my own ISO with SAS support? Should I 'kexec' my own kernel from regular upgrade ISO image?
<jaeger> If you're in a hurry, probably the easiest way would be to use some other live CD environment to install, with a kernel that has that driver enabled... for the longer term I can add it to the kernel config of the updated ISO
<ukky> jaeger: Thanks! I am not in a hurry. The rootfs is already created on SATA and I will chroot into CRUX rootfs from Gentoo host, my current OS. Just worry about next upgrade when I remove Gentoo from my system.
<SiFuh> Hmm, jaeger my config has SAS because I use to use SAS for my LTO5
<SiFuh> You'd only need to add a few of these lines https://dpaste.com/5CNVAL5SL.txt Probably not the last two though. Since ukky has SAS, he could test the configuration
<jaeger> I have SAS controllers as well, just not the same one
<jaeger> They work fine, no surprises
<SiFuh> Mine was through PCMCIA
<SiFuh> This one
<jaeger> The one in question here is CONFIG_SCSI_ISCI, I believe
<jaeger> ukky: what does lspci -k say about the module in use for that controller on the gentoo system?
<ukky> jaeger: yes, mine needs CONFIG_SCSI_ISCI
<jaeger> ok
<ukky> 03:00.0 Serial Attached SCSI controller [0107]: Intel Corporation C600/X79 series chipset Dual 4-Port SATA/SAS Storage Control Unit [8086:1d64] (rev 06)
<ukky> Kernel driver in use: isci
<SiFuh> Intel(R) C600 Series Chipset SAS Controller
<ukky> SiFuh: yes
<ukky> My kernel also needs this: CONFIG_EXTRA_FIRMWARE="isci/isci_firmware.bin"
<SiFuh> Easy one to enable. You should only need these with the your SCSI stuff, SCSI_SAS_LIBSAS, SCSI_ISCI, SCSI_SAS_ATTRS, FUSION_SAS
<ukky> I also have CONFIG_SCSI_SAS_ATA
<ukky> New CRUX install will have static /dev, i.e. no udev/eudev/mdev/systemd
<jaeger> Do you actually use libata support for libsas or was that just enabled as a test or something?
<ukky> checking...
<jaeger> That's the CONFIG_SCSI_SAS_ATA option
<ukky> I think libata (CONFIG_ATA) is required for SATA devices, unless you are asking about CONFIG_SCSI_SAS_ATA
<jaeger> Specifically asking about the latter
<SiFuh> CONFIG_SCSI_SAS_ATA Builds in ATA support into libsas. Will necessitate the loading of libata along with libsas.
<jaeger> Hence the question "Do you actually use libata support for libsas or..."
<ukky> I have both SATA (4 disks) and SAS (2 disks) attached to SAS controller. It has 4 ports for SATA and 4 ports for SAS-only devices. Not sure if SATA-over-SAS-controller will work without CONFIG_SCSI_SAS_ATA. I can test if you need to make sure it is used
<jaeger> I would be surprised if libata support for libsas were actually a requirement for anything, but if you have time to test, sure
<SiFuh> I would be surprised too
ukky_ has joined #crux
ukky has quit [Ping timeout: 276 seconds]
jason123onirc has quit [Ping timeout: 255 seconds]
jason123santaoni has joined #crux
ukky_ has quit [Quit: Rebooting...]
ukky has joined #crux
<ukky> jaeger: Just tested. CONFIG_SCSI_SAS_ATA is required. When this option is off, even regular SATA disk (controller in AHCI mode) is not detected. SATA drives behind SAS controller are not detected. But all SAS drives are detected.
<ukky> Error message from dmesg: sas: ATA device seen but CONFIG_SCSI_SAS_ATA=N so cannot attach
<ukky> SATA disk behind USB controller is detected
<cruxbot> [contrib.git/3.7]: docker: updated to version 23.0.2
<cruxbot> [contrib.git/3.7]: runc: updated to version 1.1.5
<jaeger> Must be hardware-specific, CONFIG_SCSI_SAS_ATA is definitely not needed for hardware I have. I don't mind adding it, just wanted to be sure. Thanks for testing.
<ukky> The fact that even regular SATA drive behind SATA AHCI controller was not detected, is very strange
<jaeger> Agreed... on all hardware I have with AHCI controllers that is not the case... That's why I think it must be specific to your chipset
<jaeger> Maybe that controller isn't a standard AHCI controller but instead has some kind of layer over SAS?
<jaeger> All SAS controllers should be able to control SATA drives as well but I don't know the details of how that happens under the hood.
<ukky> But it could be also HW malfanction. Yesterday my SATA drive was not detected at all in one boot, then I switched SATA port and it was detected again.
<jaeger> Perhaps
<ukky> On a PCI bus there are two independent devices, [8086:1d02] (SATA AHCI controller) and [8086:1d64] (SATA/SAS controller)
<ukky> There is also a special SAS ROM chip to enable SAS functionality.
deep42thought has joined #crux
deep42thought has quit [Read error: Connection reset by peer]
ukky has quit [Quit: Fixing System BIOS settings]
<SiFuh> jaeger: Looks like it is not a hardware issue. Seems some drivers require ATA discovery.
<SiFuh> Page 37 is a start
ukky has joined #crux
<SiFuh> ukky: Seems some drivers require ATA after discovery to attach.
<SiFuh> Gentoo had enabled that feature as well for this very reason
<ukky> Gentoo does not enforce that option. Maybe in precompiled kernel, or in auto-generated kernel (genkernel). That is not applied to my kernel, as I use my kernel config, and I do not see 'select SCSI_SAS_ATA' in any Kconfig.
<SiFuh> Hmm what was I looking at then? Let me check history
<jaeger> Same thing in the end... not a hardware 'issue' but that hardware uses a driver that needs the feature
<ukky> If user does not attach SATA devices to SAS controller, then this feature is not required. So, it seems like runtime dependency :-)
<jaeger> Depends on the SAS controller, too
<jaeger> I have some LSI controllers that don't seem to need it
<jaeger> In any case, https://crux.nu/gitweb/?p=system/iso.git;a=commit;h=72d271d98f61990c23d92cc5085f07f579e46a02
<SiFuh> I saw that the error message from dmesg was deliberately added later on to notify the user that the option needs to be set to Y in the kernel
<SiFuh> https://lwn.net/Articles/277619/ search CONFIG_SCSI_SAS_ATA
<SiFuh> That's cool jaeger. I guess only ukky is able to test that commit though.
<jaeger> Is that a problem? :)
<SiFuh> If no one tests then yes :-P How do we know if it works?
<jaeger> If nobody tests it, nobody's using it. Then it doesn't matter.
<SiFuh> Heh, except ukky
maledictium has quit [Ping timeout: 250 seconds]
<jaeger> If ukky tests it, then it's no untested :)
<jaeger> s/no/not/
<ukky> Of course I will test it, when ready
<jaeger> I've got a new build running now, will let you know when it's uploaded
tilman has quit [Ping timeout: 250 seconds]
maledictium has joined #crux
tilman has joined #crux
<ukky> okay, I cannot test it immediately anyway. I already took apart my HDD connections a few times today. Moved swap disk to SATA (AHCI), as AHCI disk is not properly detected for some reason.
<jaeger> No worries
<ukky> But I will probably need an ISO, as my CRUX setup is not ready on this system
tilman has quit [Ping timeout: 252 seconds]
tilman has joined #crux
jason123santaoni is now known as jason123onirc
Romster has quit [Ping timeout: 250 seconds]
Romster has joined #crux
tilman has quit [Ping timeout: 255 seconds]
tilman has joined #crux