Re: x86_64 SATA DVD drive + libata trouble
Hello, sorry for the large amount of files in my last mail, which will be outdated by this mail. Had I only read a little bit further on the bugzilla page. Robert Hancock wrote: > There is a known problem with ATAPI devices on CK804 chipsets > which have memory above the 4GB mark, being debugged here: > > https://bugzilla.redhat.com/show_bug.cgi?id=351451 There is a second patch on this bugzilla page which I did not see in the first place. https://bugzilla.redhat.com/attachment.cgi?id=254191 This patch gives me a working 2.6.24-rc1-git10 kernel WITH adma and with the full 8GB of RAM. See the attached dmesg text file below. > > If you are running into that one you can workaround it for now > by passing the adma=0 parameter to the sata_nv module (not sure > how this would be done on Suse's setup) or pass sata_nv.adma=0 > on the kernel command line if sata_nv is built into the kernel. > If that does help, I could ask you to test patches :-) Obviously there is no need for more patches to get the drive working. I will probably just use that working kernel after some testing. And if I get to know that the patch gets upstream, then I will probably use 2.6.24 when it is finished. If there are more patches to test on this problem please let me hear. Now I have a setup that makes testing a patch taking a lot less time than before. Thanks for the help, Bernd Strieder Linux version 2.6.24-rc1-git10-default ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE Linux)) #1 SMP Mon Nov 12 15:55:37 CET 2007 Command line: root=/dev/disk/by-id/scsi-1AMCC_0278095931E5540026BE-part2 vga=0x31aresume=/dev/sda1 splash=silent 3 BIOS-provided physical RAM map: BIOS-e820: - 0009ac00 (usable) BIOS-e820: 0009ac00 - 000a (reserved) BIOS-e820: 000da000 - 0010 (reserved) BIOS-e820: 0010 - 7ff0 (usable) BIOS-e820: 7ff0 - 7ff11000 (ACPI data) BIOS-e820: 7ff11000 - 7ff8 (ACPI NVS) BIOS-e820: 7ff8 - 8000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec00400 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) BIOS-e820: 0001 - 00028000 (usable) Entering add_active_range(0, 0, 154) 0 entries of 3200 used Entering add_active_range(0, 256, 524032) 1 entries of 3200 used Entering add_active_range(0, 1048576, 2621440) 2 entries of 3200 used end_pfn_map = 2621440 DMI present. ACPI: RSDP 000F78C0, 0014 (r0 PTLTD ) ACPI: RSDT 7FF0B188, 0040 (r1 PTLTDRSDT604 LTP0) ACPI: FACP 7FF10A3E, 0074 (r1 NVIDIA CK8S 604 PTL_F4240) ACPI: DSDT 7FF0B1C8, 5876 (r1 NVIDIA CK8 604 MSFT 10E) ACPI: FACS 7FF11FC0, 0040 ACPI: SRAT 7FF10AB2, 0110 (r1 AMDHAMMER604 AMD 1) ACPI: SPCR 7FF10BC2, 0050 (r1 PTLTD $UCRTBL$ 604 PTL 1) ACPI: MCFG 7FF10C12, 003C (r1 PTLTDMCFG604 0) ACPI: APIC 7FF10C4E, 009E (r1 PTLTD APIC604 LTP0) ACPI: BOOT 7FF10CEC, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 7FF10D14, 02EC (r1 PTLTD POWERNOW 604 LTP1) SRAT: PXM 0 -> APIC 0 -> Node 0 SRAT: PXM 0 -> APIC 1 -> Node 0 SRAT: PXM 1 -> APIC 2 -> Node 1 SRAT: PXM 1 -> APIC 3 -> Node 1 SRAT: Node 0 PXM 0 0-a Entering add_active_range(0, 0, 154) 0 entries of 3200 used SRAT: Node 0 PXM 0 0-8000 Entering add_active_range(0, 0, 154) 1 entries of 3200 used Entering add_active_range(0, 256, 524032) 1 entries of 3200 used SRAT: Node 0 PXM 0 0-18000 Entering add_active_range(0, 0, 154) 2 entries of 3200 used Entering add_active_range(0, 256, 524032) 2 entries of 3200 used Entering add_active_range(0, 1048576, 1572864) 2 entries of 3200 used SRAT: Node 1 PXM 1 18000-28000 Entering add_active_range(1, 1572864, 2621440) 3 entries of 3200 used NUMA: Using 31 for the hash shift. Bootmem setup node 0 -00018000 Bootmem setup node 1 00018000-00028000 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 2621440 Movable zone start PFN for each node early_node_map[4] active PFN ranges 0:0 -> 154 0: 256 -> 524032 0: 1048576 -> 1572864 1: 1572864 -> 2621440 On node 0 totalpages: 1048218 DMA zone: 56 pages used for memmap DMA zone: 1028 pages reserved DMA zone: 2910 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 505656 pages, LIFO batch:31 Normal zone: 7168 pages used for memmap Normal zone: 517120 pages, LIFO batch:31 Movable zone: 0 pages used for memmap On node 1 totalpages: 1048576 DMA zone: 0 pages used for memmap DMA32 zone: 0 pages used for memmap Normal zo
Re: x86_64 SATA DVD drive + libata trouble
Hello, sorry for the large amount of files in my last mail, which will be outdated by this mail. Had I only read a little bit further on the bugzilla page. Robert Hancock wrote: There is a known problem with ATAPI devices on CK804 chipsets which have memory above the 4GB mark, being debugged here: https://bugzilla.redhat.com/show_bug.cgi?id=351451 There is a second patch on this bugzilla page which I did not see in the first place. https://bugzilla.redhat.com/attachment.cgi?id=254191 This patch gives me a working 2.6.24-rc1-git10 kernel WITH adma and with the full 8GB of RAM. See the attached dmesg text file below. If you are running into that one you can workaround it for now by passing the adma=0 parameter to the sata_nv module (not sure how this would be done on Suse's setup) or pass sata_nv.adma=0 on the kernel command line if sata_nv is built into the kernel. If that does help, I could ask you to test patches :-) Obviously there is no need for more patches to get the drive working. I will probably just use that working kernel after some testing. And if I get to know that the patch gets upstream, then I will probably use 2.6.24 when it is finished. If there are more patches to test on this problem please let me hear. Now I have a setup that makes testing a patch taking a lot less time than before. Thanks for the help, Bernd Strieder Linux version 2.6.24-rc1-git10-default ([EMAIL PROTECTED]) (gcc version 4.2.1 (SUSE Linux)) #1 SMP Mon Nov 12 15:55:37 CET 2007 Command line: root=/dev/disk/by-id/scsi-1AMCC_0278095931E5540026BE-part2 vga=0x31aresume=/dev/sda1 splash=silent 3 BIOS-provided physical RAM map: BIOS-e820: - 0009ac00 (usable) BIOS-e820: 0009ac00 - 000a (reserved) BIOS-e820: 000da000 - 0010 (reserved) BIOS-e820: 0010 - 7ff0 (usable) BIOS-e820: 7ff0 - 7ff11000 (ACPI data) BIOS-e820: 7ff11000 - 7ff8 (ACPI NVS) BIOS-e820: 7ff8 - 8000 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - fec00400 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: fff8 - 0001 (reserved) BIOS-e820: 0001 - 00028000 (usable) Entering add_active_range(0, 0, 154) 0 entries of 3200 used Entering add_active_range(0, 256, 524032) 1 entries of 3200 used Entering add_active_range(0, 1048576, 2621440) 2 entries of 3200 used end_pfn_map = 2621440 DMI present. ACPI: RSDP 000F78C0, 0014 (r0 PTLTD ) ACPI: RSDT 7FF0B188, 0040 (r1 PTLTDRSDT604 LTP0) ACPI: FACP 7FF10A3E, 0074 (r1 NVIDIA CK8S 604 PTL_F4240) ACPI: DSDT 7FF0B1C8, 5876 (r1 NVIDIA CK8 604 MSFT 10E) ACPI: FACS 7FF11FC0, 0040 ACPI: SRAT 7FF10AB2, 0110 (r1 AMDHAMMER604 AMD 1) ACPI: SPCR 7FF10BC2, 0050 (r1 PTLTD $UCRTBL$ 604 PTL 1) ACPI: MCFG 7FF10C12, 003C (r1 PTLTDMCFG604 0) ACPI: APIC 7FF10C4E, 009E (r1 PTLTD APIC604 LTP0) ACPI: BOOT 7FF10CEC, 0028 (r1 PTLTD $SBFTBL$ 604 LTP1) ACPI: SSDT 7FF10D14, 02EC (r1 PTLTD POWERNOW 604 LTP1) SRAT: PXM 0 - APIC 0 - Node 0 SRAT: PXM 0 - APIC 1 - Node 0 SRAT: PXM 1 - APIC 2 - Node 1 SRAT: PXM 1 - APIC 3 - Node 1 SRAT: Node 0 PXM 0 0-a Entering add_active_range(0, 0, 154) 0 entries of 3200 used SRAT: Node 0 PXM 0 0-8000 Entering add_active_range(0, 0, 154) 1 entries of 3200 used Entering add_active_range(0, 256, 524032) 1 entries of 3200 used SRAT: Node 0 PXM 0 0-18000 Entering add_active_range(0, 0, 154) 2 entries of 3200 used Entering add_active_range(0, 256, 524032) 2 entries of 3200 used Entering add_active_range(0, 1048576, 1572864) 2 entries of 3200 used SRAT: Node 1 PXM 1 18000-28000 Entering add_active_range(1, 1572864, 2621440) 3 entries of 3200 used NUMA: Using 31 for the hash shift. Bootmem setup node 0 -00018000 Bootmem setup node 1 00018000-00028000 Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 2621440 Movable zone start PFN for each node early_node_map[4] active PFN ranges 0:0 - 154 0: 256 - 524032 0: 1048576 - 1572864 1: 1572864 - 2621440 On node 0 totalpages: 1048218 DMA zone: 56 pages used for memmap DMA zone: 1028 pages reserved DMA zone: 2910 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 505656 pages, LIFO batch:31 Normal zone: 7168 pages used for memmap Normal zone: 517120 pages, LIFO batch:31 Movable zone: 0 pages used for memmap On node 1 totalpages: 1048576 DMA zone: 0 pages used for memmap DMA32 zone: 0 pages used for memmap Normal zone: 14336 pages used for memmap Normal zone: 1034240 pages, LIFO batch:31 Movable zone: 0 pages used
x86_64 SATA DVD drive + libata trouble
Hello, please CC me, I'm not subscribed. If any kernel developer is interested in more specific information please mail me, I can build kernels, I can apply patches, though have not done it regularly. I'd like to get the DVD drive working somehow. I have googled a lot and did not find any more ideas what to do. Some good keywords to find a solution would suffice at that end. Rough problem description: I have a Tyan mainboard with NVIDIA chipset CK804. The only SATA/IDE device is a SATA DVD combo, the harddisks are on a RAID controller from 3ware. The harddisks are fine. The openSuSE 10.3 boot dvds fail after booting from the BIOS, the installation kernel cannot use the DVD drive. That kernel uses libata and sata_nv pata_amd as drivers. The drive is recognized but it cannot be used. This is the situation probably during install from DVD and now in the running system after a network install it persists. Reading from the dvd device /dev/sr0 with dd stops after at most 119kb of rubbish read. Mounting fails with superblock not found. When trying to remove the pata_amd module I get an Oops. I tried to remove the modules to have a chance to reload them with other options (atapi_enable), but that did not help, even after rebooting. A vanilla 2.6.23.1 kernel behaves even less friendly, the dd on /dev/sr0 causes a hard reset. So there are clearly some problems with libata in this system. I have failed switching away from libata getting the drive to be recognized at all. Thanks for any help, Bernd Strieder - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
x86_64 SATA DVD drive + libata trouble
Hello, please CC me, I'm not subscribed. If any kernel developer is interested in more specific information please mail me, I can build kernels, I can apply patches, though have not done it regularly. I'd like to get the DVD drive working somehow. I have googled a lot and did not find any more ideas what to do. Some good keywords to find a solution would suffice at that end. Rough problem description: I have a Tyan mainboard with NVIDIA chipset CK804. The only SATA/IDE device is a SATA DVD combo, the harddisks are on a RAID controller from 3ware. The harddisks are fine. The openSuSE 10.3 boot dvds fail after booting from the BIOS, the installation kernel cannot use the DVD drive. That kernel uses libata and sata_nv pata_amd as drivers. The drive is recognized but it cannot be used. This is the situation probably during install from DVD and now in the running system after a network install it persists. Reading from the dvd device /dev/sr0 with dd stops after at most 119kb of rubbish read. Mounting fails with superblock not found. When trying to remove the pata_amd module I get an Oops. I tried to remove the modules to have a chance to reload them with other options (atapi_enable), but that did not help, even after rebooting. A vanilla 2.6.23.1 kernel behaves even less friendly, the dd on /dev/sr0 causes a hard reset. So there are clearly some problems with libata in this system. I have failed switching away from libata getting the drive to be recognized at all. Thanks for any help, Bernd Strieder - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SCSI modules and kmod
Hello,
the problem is, that SCSI hostadapter modules seem not to be loaded
automatically, whenever there is another hostadaptor active already, or
if IDE SCSI emulation is enabled.
Loading automatically is usually done via having kmod load the virtual
module "scsi_hostadapter", which is usually translated by modprobe via
an entry in /etc/modules.conf to the right module to be loaded. This
doesn't happen in my case. Instead there is a message from modprobe,
that module block-major-8 (/dev/sda...) could not be loaded, so there is
something tried.
The following is from linux/drivers/scsi/scsi.c:
int scsi_register_module(int module_type, void * ptr)
{
switch(module_type)
{
case MODULE_SCSI_HA:
return scsi_register_host((Scsi_Host_Template *) ptr);
/* Load upper level device handler of some kind */
case MODULE_SCSI_DEV:
#ifdef CONFIG_KMOD
if (scsi_hosts == NULL)
request_module("scsi_hostadapter");
#endif
return scsi_register_device_module((struct Scsi_Device_Template
*) ptr);
/* The rest of these are not yet implemented */
/* Load constants.o */
case MODULE_SCSI_CONST:
/* Load specialized ioctl handler for some device. Intended for
* cdroms that have non-SCSI2 audio command sets. */
case MODULE_SCSI_IOCTL:
default:
return 1;
}
}
It seems to be the case that scsi_hosts != NULL holds, whenever ide-scsi
is enabled. This prevents other (real) SCSI adapter drivers from being
loaded automatically.
What could be done?
Perhaps it is better to try first to find the device. If that fails try
to load the module, then try once again to register the device.
In other words changing the case of the function above like the
following could perhaps do it.
int regdevresult;
case MODULE_SCSI_DEV:
#ifdef CONFIG_KMOD
if (scsi_hosts == NULL)
{
request_module("scsi_hostadapter");
return scsi_register_device_module((struct
Scsi_Device_Template *) ptr);
}
#endif
regdevresult = scsi_register_device_module((struct
Scsi_Device_Template *) ptr);
#ifdef CONFIG_KMOD
if (regdevresult != 0) /* is this the right case? */
request_module("scsi_hostadapter");
regdevresult = scsi_register_device_module((struct
Scsi_Device_Template *) ptr);
#endif
return regdevresult;
This would be the first time I really change the kernel, so I thought
it'd be better to ask, if this could work before losing too much time.
The only change in behaviour will be that trying to access a SCSI device
that isn't there will result in as many calls to modprobe as accesses
are tried. The current code will only show this, if scsi_hosts == NULL
and remains so after loading the module. This is not a major change, and
it will happen just in cases of misconfiguration of the system.
It is important that the kernel tries to tell modprobe that it looks for
a SCSI hostadapter. "modprobe" itself can do a lot more with that, e.g.
loading multiple SCSI drivers, loading other modules, etc.
Please CC me in answers, I'm not in the list.
Bernd Strieder
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
