Problem with SDHC

[AlienSoldier]

PANIC:map_backing_store() : called with size=0 for area 'sdhc_regs_map'

I get this with my latest Toshiba laptop update. Does it on every boot.

[AlienSoldier]

This is a syslog from another partition, the syslog of the partition with the problem does not even populate with data.

[pulkomandy]

Proposed fix in ​https://review.haiku-os.org/c/haiku/+/3682 .

[AlienSoldier]

No longer have a Panic but now the boot icons light up including the "disk" icon (the one with the leaf) but no disk activity happen from there. The Chip icon never light up and it stay like that to the infinity and beyond. Nothing get written to Syslog.

[pulkomandy]

from that state (wait a few seconds after disk activity stops) press control printscreen d to enter KDL and type "syslog" to get the log. You will have to take pictures of it.

It's ok to skip some pages but try to get everything from sdhci_pci and mmc_disk (you can see them easily, the name is written in yellow at the start of the lines)

Unfortunately it doesn't get written to disk when a disk driver has a bug.

If you want to use your computer until this is fixed you can blacklist the sdhci_pci driver.

[AlienSoldier]

I try control printscreen and D all at the same time and it does nothing. I don't know if this is because toshiba laptop are often non standard on many front, anyway i also connected a USB external keyboard and is also do nothing. I also test alt instead of control as mentioned here ​https://en.wikipedia.org/wiki/KDL. I think D is at the same place in Azerty or Querty.

[pulkomandy]

Different strategy then: from the bootloader menu, enable "on screen debug". The syslog will appear as the system is booting. Then, same thing, take pictures of the screens where there is sdhci_pci or mmc_disk activity.

[AlienSoldier]

I hope the first one is readable enough, it is harder to not blur white on black text.

[AlienSoldier]

I ran it again just to see if it was the same everytime. The bootloader itself seem to have a problem. I use my HD4 partition, yet the system mention the current one after i press the space bar to be HD3. I go select HD4-latest and when i climb back from that menu it still say HD3. I selected the closest one with a date on the top, got out of menu and it no longer mention HD3, so i got back and selected HD4-latest and got out and when i do all this it keep HD4-latest and i can continue booting.

With that out of the way, this time i don't get a Panic at the end and the following lines got printed and then all is frozen and i can't even type a thing:

mmc_disk: CALLED float mmc_disk_supports_device(device_node *)
mmc_disk: Could not get device type
sdhi_pci: CALLED status_t init_bus(device_node *, void **)
sdhi_pci:  Register SD bus at slot 3, using bar 3
sdhi_pci: no register to map driver busses/mmc/sdhci_pci/device/v1 init failed General system error
mmcbus: CALLED void mmc_bus_uninit(void *)
mmcbus: CALLED MMCBus()

[pulkomandy]

I don't see anything too bad with the logs you provided now. This device is a bit special because apparently it does not only SD cards, but also other card types, and the driver needs to be careful about this.

But now it detects that no cards are inserted, and that should not prevent booting further.

Does it work if you blacklist the sdhci_pci driver? Just to make sure the driver is at fault and I should look at it closer, or if there's another problem elsewhere.

[AlienSoldier]

Blacklisting sdhci_pci allow to boot up correctly. I guess i need to fill a new ticket about my boot manager problem. Even when reinstalling it (made it to boot on HD1, then back to HD4 to make sure it won't stick to HD3 anymore) the problem remain (very annoying). Also "the latest" is not listed in the date list of bootman so we can't easilly have any idea of what version it could be when you can't boot at all to look at it in "Haiku About" ).

As for the card reader, i does SD, XD and memory stick. I don't have any XD card but i have the others. I also tested booting with a card in at boot and it does not boot further (did not try with a memory stick in at boot that said).

[pulkomandy]

I guess you manually copied the messages from the log? I appreciate the effort but it appears there are some slight differences from the messages in the sourcecode and that makes it difficult for me to find exactly where they come from.

So I'm guessing:

sdhi_pci: no register to map

is in fact:

sdhi_pci: No register to map

And

mmcbus: CALLED MMCBus()

Is in fact:

mmcbus: CALLED ~MMCBus()

If that's the case, I think I see part of what's going wrong. But I was not able to locate where init failed General system error comes from.

[pulkomandy]

Ok, my best guess with these logs is that ​https://review.haiku-os.org/c/haiku/+/3773 should fix it. Can you try that?

[AlienSoldier]

Can sure try once it is in nightly, not before. Seem it is still in review limbo at this point?

[pulkomandy]

I would have preferred confirmation that it fixes the problem before merging it, because it's only a guess from incomplete logs. But if you are not set up to compile it by yourself, I will merge it anyway

[AlienSoldier]

Just let me know the revision it will be in, that way i will test it as soon as i see it available.

[madmax]

Replying to AlienSoldier:

Can sure try once it is in nightly, not before.

If you trust files from random guys from the internet, I've compiled hrev54985 with change 3773 applied on top for x86_gcc2h. No guarantees, use it at your own risk, your house may burn down in flames, kittens may die, etc.

Configure options: --use-gcc-pipe --use-gcc-graphite --include-sources --cross-tools-prefix <x86_gcc2 prefix> --cross-tools-prefix <x86 prefix>

Build: jam -sHAIKU_REVISION=hrev54985_3773 -sHAIKU_BUILD_ATTRIBUTES_DIR=<some dir> -sHAIKU_IMAGE_SIZE=900 -q @nightly-anyboot

I also had to add -Wno-error=maybe-uninitialized due to an error in src/add-ons/translators/raw/RAW.cpp that I don't understand, so I don't know if you'd be getting a different bug.

I've only tested that the image boots in qemu, I can install it and reboot the install to desktop.

For limited time you can get the iso (900MB) from: ​http://static.movingborders.es/hrev54985_3773_x86_gcc2h/haiku-nightly-anyboot.iso

Edit the "file part" if one of the hpkgs is enough. SHA256 binary checksums:

8070acec1c5c27720c92174e343a2d33cfb3d9ae0f147e98523873a1b2d08e5e *haiku_devel.hpkg
84a1f6e959ccda25c94075ec982b38a415ea611cf6070bc2b470890bc0092a79 *haiku_extras.hpkg
608bd0fc3de1eba4c44c77eb1ff0895881e23a33b1d30ee1230c6fb2f4371526 *haiku.hpkg
c2cdc9022aa3cf37f748506b707126136b4c0eddcb66f60e7da1adf7566da570 *haiku_loader.hpkg
2df2f21a7bb114cb6dcd453f09d48a943e90687015cc16550f453fa9bf9af76d *haiku-nightly-anyboot.iso
7056d34dd24c19954bf9f963c296972f1f171b393850409515b8e5e23501a495 *haiku_source.hpkg
8b9746170c5335ed019c3a1aefe24ece4a4771163e212552855d41a37b24cd54 *haiku_x86_devel.hpkg
99653a8e7e34fb7e6bad74c9cdc2ddc4898f273ada354334262610046e6b9874 *haiku_x86.hpkg

[edited to remove --distro-compatibility option and update checksums]

[pulkomandy]

Off-topic rant: using --distro-compatibility official in this case is not great :) Please avoid it if you can when you redistribute images.

Thanks for your help still, and sorry to be picky about these things.

[pulkomandy]

The change is merged as of hrev54988. Let me know if your computer boots again, and if the SD card reader works.

[AlienSoldier]

laptop boot fine, SD card still not seen. I am adding the new syslog.

[pulkomandy]

Ok, we're making progress.

First there was an error in computing the bar numbers. I have fixed it in hrev54991.

Then, I see something strange and I don't know what to make of it.

In the initial PCI enumeration we see this:

KERN: PCI: [dom 0, bus  6] bus   6, device  4, function  4: vendor 104c, device 8034, revision 00
KERN: PCI:   class_base 08, class_function 05, class_api 00
KERN: PCI:   vendor 104c: Texas Instruments
KERN: PCI:   device 8034: PCIxx21/PCIxx11 SD Host Controller
KERN: PCI:   info: Generic system peripheral (SD Host controller)
KERN: PCI:   line_size 08, latency 39, header_type 80, BIST 00
KERN: PCI:   ROM base host 00000000, pci 00000000, size 00000000
KERN: PCI:   cardbus_CIS 00000000, subsystem_id ff05, subsystem_vendor_id 1179
KERN: PCI:   interrupt_line 0a, interrupt_pin 04, min_grant 07, max_latency 04
KERN: PCI:   base reg 0: host bc009400, pci bc009400, size 00000100, flags 00
KERN: PCI:   base reg 1: host bc009000, pci bc009000, size 00000100, flags 00
KERN: PCI:   base reg 2: host bc006400, pci bc006400, size 00000100, flags 00
KERN: PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   Capabilities: PM

In particular there is this information: interrupt_line 0a

But later on when the SD driver initializes we see this:

KERN: [33msdhci_pci:[0m supports_device(vid:104c pid:8034)
KERN: [33msdhci_pci:[0m SDHCI Device found! Subtype: 0x0005, type: 0x0008
KERN: [33msdhci_pci:[0m CALLED status_t init_device(device_node *, void **)
KERN: [33msdhci_pci:[0m CALLED status_t register_child_devices(void *)
KERN: [33msdhci_pci:[0m CALLED status_t init_bus(device_node *, void **)
KERN: [33msdhci_pci:[0m Register SD bus at slot 1, using bar 0
KERN: [33msdhci_pci:[0m interrupts count: 0
KERN: [33msdhci_pci:[0m irq interrupt line: 19
KERN: [33msdhci_pci:[0m Card not inserted, not powering on for no

The interrupt has become 19. Why has it changed between these two steps? Is that ok?

Can someone explain how interrupts are managed? Is this normal, or is it unexpected?

In case that's useful, the documentation for this device is available online, for example here: ​https://pdf1.alldatasheet.com/datasheet-pdf/view/118234/TI/PCI6411.html

[korli]

ACPICA tries to update io-apic routing for this device but fails (I don't know what to do with this):

KERN: failed to update interrupt_line for PCI 6:4 mask 1

[tqh]

It's our PCI code: ​https://github.com/haiku/haiku/blob/3f6f7f7420d37dd080d5d04d7c1c539142f732b6/src/system/kernel/arch/x86/irq_routing_table.cpp#L865

[AlienSoldier]

"First there was an error in computing the bar numbers. I have fixed it in hrev54991."

I added a new syslog hrev54997 in case you want to see if something changed related to that fix.

[pulkomandy]

Replying to korli:

ACPICA tries to update io-apic routing for this device but fails (I don't know what to do with this):

KERN: failed to update interrupt_line for PCI 6:4 mask 1

This has a function mask of 1 (function 0, mask = 1 << 0), but I'm interested in function 4 (mask 10 = 1 << 4).

Here is a larger extract of the log with all the functions provided by this device:

KERN: PCI: [dom 0, bus  6] bus   6, device  4, function  0: vendor 104c, device 8031, revision 00
KERN: PCI:   class_base 06, class_function 07, class_api 00
KERN: PCI:   vendor 104c: Texas Instruments
KERN: PCI:   device 8031: PCIxx21/PCIxx11/PCIx515 PC Card Controller
KERN: PCI:   info: Bridge (CardBus bridge)
KERN: PCI:   line_size 08, latency 40, header_type 82, BIST 00
KERN: PCI:   subsystem_id ff00, subsystem_vendor_id 1179
KERN: PCI:   primary_bus 06, secondary_bus 07, subordinate_bus 07, secondary_latency 24
KERN: PCI:   bridge_control 0344, secondary_status 0200
KERN: PCI:   memory_base_upper32  00000000, memory_base  00000000
KERN: PCI:   memory_limit_upper32 00000000, memory_limit 00000000
KERN: PCI:   io_base_upper32  00000000, io_base  00000000
KERN: PCI:   io_limit_upper32 00000000, io_limit 00000000
KERN: PCI:   Capabilities: PM
KERN: PCI: [dom 0, bus  6] bus   6, device  4, function  2: vendor 104c, device 8032, revision 00
KERN: PCI:   class_base 0c, class_function 00, class_api 10
KERN: PCI:   vendor 104c: Texas Instruments
KERN: PCI:   device 8032: OHCI Compliant IEEE 1394 Host Controller
KERN: PCI:   info: Serial bus controller (FireWire (IEEE 1394), OHCI)
KERN: PCI:   line_size 08, latency 20, header_type 80, BIST 00
KERN: PCI:   ROM base host 00000000, pci 00000000, size 00000000
KERN: PCI:   cardbus_CIS 00000000, subsystem_id ff00, subsystem_vendor_id 1179
KERN: PCI:   interrupt_line 0b, interrupt_pin 03, min_grant 02, max_latency 04
KERN: PCI:   base reg 0: host bc006800, pci bc006800, size 00000800, flags 00
KERN: PCI:   base reg 1: host bc000000, pci bc000000, size 00004000, flags 00
KERN: PCI:   base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, fKERN: lags 00
KERN: PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   Capabilities: PM
KERN: PCI: [dom 0, bus  6] bus   6, device  4, function  3: vendor 104c, device 8033, revision 00
KERN: PCI:   class_base 01, class_function 80, class_api 00
KERN: PCI:   vendor 104c: Texas Instruments
KERN: PCI:   device 8033: PCIxx21/PCIxx11 Flash Media Controller
KERN: PCI:   info: Mass storage controller
KERN: PCI:   line_size 08, latency 39, header_type 80, BIST 00
KERN: PCI:   ROM base host 00000000, pci 00000000, size 00000000
KERN: PCI:   cardbus_CIS 00000000, subsystem_id ff05, subsystem_vendor_id 1179
KERN: PCI:   interrupt_line 0a, interrupt_pin 02, min_grant 07, max_latency 04
KERN: PCI:   base reg 0: host bc004000, pci bc004000, size 00002000, flags 00
KERN: PCI:   base reg 1: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   base reg 2: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   base reg 3: host 00000000, pci 00000000, size 00000000,
 flags 00
KERN: PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   Capabilities: PM
KERN: PCI: [dom 0, bus  6] bus   6, device  4, function  4: vendor 104c, device 8034, revision 00
KERN: PCI:   class_base 08, class_function 05, class_api 00
KERN: PCI:   vendor 104c: Texas Instruments
KERN: PCI:   device 8034: PCIxx21/PCIxx11 SD Host Controller
KERN: PCI:   info: Generic system peripheral (SD Host controller)
KERN: PCI:   line_size 08, latency 39, header_type 80, BIST 00
KERN: PCI:   ROM base host 00000000, pci 00000000, size 00000000
KERN: PCI:   cardbus_CIS 00000000, subsystem_id ff05, subsystem_vendor_id 1179
KERN: PCI:   interrupt_line 0a, interrupt_pin 04, min_grant 07, max_latency 04
KERN: PCI:   base reg 0: host bc009400, pci bc009400, size 00000100, flags 00
KERN: PCI:   base reg 1: host bc009000, pci bc009000, size 00000100, flags 00
KERN: PCI:   base reg 2: host bc006400, pci bc006400, size 00000100, flags 00
KERN: PCI:   base reg 3: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   base reg 4: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   base reg 5: host 00000000, pci 00000000, size 00000000, flags 00
KERN: PCI:   Capabilities: PM

Function 0 (which corresponds to mask = 1) does not seem to have an interrupt attached to it at this point. Functions 3 and 4 have one interrupt each (not the same one).

And the interrupt table is this:

KERN: address 0x4ffff; pin 0; GSI 16; pci 6:4 pin 1 func mask 1; bios irq: 10; gsi 16; config 0x06
KERN: address 0x4ffff; pin 1; GSI 17; pci 6:4 pin 2 func mask 8; bios irq: 10; gsi 17; config 0x06
KERN: address 0x4ffff; pin 2; GSI 18; pci 6:4 pin 3 func mask 4; bios irq: 11; gsi 18; config 0x06
KERN: address 0x4ffff; pin 3; GSI 19; pci 6:4 pin 4 func mask 10; bios irq: 10; gsi 19; config 0x06

Now I don't understand why function 0 (mask 1) has an interrupt listed here, while in the previous part of the log, it didn't. But I'm not very familiar with PCI, is that expected?

[pulkomandy]

Move unsolved issues to beta 4 since there is no chance of fixing them now.

[waddlesplash]

Any changes here? Should this remain in beta4?

[AlienSoldier]

No crash on hrev55877 but i don't see any sd card volume to mount, even if i try with a simple 2G card.

I join the current syslog.

[pulkomandy]

No changes here, there is still some confusion about interrupt numbers, and interrupts don't work, so the card insertion is never detected.

Since this is no longer preventing boot, I'm fine with moving it out of beta4. Not sure what to do about it myself, as I'm not familiar enough (yet) with the interactions between PCI and ACPI for interrupts setup here.