yashsingh1/xdaforums huggingface dataset:
[Motorola Atrix 2] 1BadWolf:
I don't recall having any issues with this except with my tablet detecting it after it updated to ICS. I haven't used this in a while as I have been on NUMA for over a month. I'll reinstall PA or something of the like this weekend and see if I can find an answer for you.:thumbup:

Brought to you by time and relative dimensions in space.
[Samsung Captivate Glide] Cory_branch:
Any way to preserve a baseband when flashing a custom rom every time I flash a rom it takes away the band leaving no signal or data connection
[Samsung Captivate Glide] roothorick:
No ROM touches the baseband partition. If you don't have a valid value under About Phone the ROM doesn't like it for some reason.

What baseband are you running when it works?
[Samsung Captivate Glide] dman3285:
It means the firmware can't access the ril ... firmware=modem
[Samsung Captivate Glide] dman3285:
Need to look at build.prop and make sure is says "ro.telephony.ril_class=Smdk4210RIL" on 4.1.2 and "ro.telephony.ril_class=SamsungExynos4RIL" on 4.2.1
[Samsung Captivate Glide] Sanllian:
I have a similar issue to the one above, though the line on build.prop is correct from the line you posted

Running on CM10.1 ROM, of your work of course.
[Samsung Captivate Glide] Lysander:
I have the same issue, and the build.prop line is correct.
[Samsung Captivate Glide] dbrannon79:
Update to UCLJ3 baseband and make sure your following ALL the instructions for that Rom! Some will have you flash a kernel after the Rom is flashed!
[Samsung Captivate Glide] roothorick:
Again, you don't need UCLJ3, we *know* UCLH2 works and UCLG9 should work. UCKI2/3 may not work but we haven't confirmed that yet.
[Samsung Captivate Glide] tanmayk:
I get the same issue when i try to flash any ROM onto the i927. I am on UCLJ3 and have tried flashing almost all the roms. Everytime I flash a rom the IMEI and Baseband becomes null. I have tried using EFS Professional backup tool on the phone in order to restore the IMEI, but that hasn't helped as well. Everytime I've had to go back to flashing the UCLJ3 Stock ICS Rom to get the IMEI/Baseband back. :crying:

Has anybody faced and solved this problem? I would really like to start trying out the PAC-Man roms that Kick's been building.
[Samsung Captivate Glide] tanmayk:
EDIT: Bump!! Anybody??
[Samsung Captivate Glide] roothorick:
FYI, I've been having issues with UCLH2. It works for a while, but I'll suddenly be without service in an area I know has good service, and won't be able to connect to anything besides Wi-Fi until I reboot. I'm also having issues with Odin... I didn't know LiteROM bundles the latest baseband, I'll have to try that!
[Samsung Captivate Glide] croolyc:
Same here, but for me this isn't problem.

Somehow gsm modem freez on boot, device restart helps
[Samsung Captivate Glide] idulkoan:
hardware or software?

---
[Samsung Captivate Glide] tanmayk:
Is there anyone who could help with this??
[Samsung Captivate Glide] idulkoan:
hmm

---
[Samsung Captivate Glide] AndyYan:
Guys, if I am right, this is heavily similar to the problem I was stuck in a few days ago - I also got no signal on all AOSP custom ROMs (see my discussion with [MENTION=5112223]bubor[/MENTION] in the CM10.2 thread). This is solved for me via the terminal commands:

su

chown radio.radio /efs/nv*

Hope it also works for you.

Sent from Samsung Captivate Glide @ CM10.1.2
[Samsung Captivate Glide] idulkoan:
tegra 2..

---
[Samsung Captivate Glide] nemo.:
While I think that this is fixable and may very well be a driver issue I don't know this for certain yet.

It would be really helpful if more users would look in their dmesgs and report what they see in respect to the

USB messages (bus loss, highspeed negoation, etc.).

Additionally it would be interesting if this problem only exists on ATT phones.

Update:

Some related threads:

- http://xdaforums.com/showthread.php?t=2077841

- http://xdaforums.com/showthread.php?t=2137681

- http://xdaforums.com/showthread.php?t=2028824

No solution yet, I guess. Haven't got time to debug the issue myself.

I'd appreciate if someone could throw some ideas on the issue,

I don't really know where to start debugging, I might try to debug

the tegra USB driver...
[Samsung Captivate Glide] nemo.:
First of all, thanks for investigating as well.

Yes, it happens on the stock ROM as well, but not indefinitely. After a few attempts the connection is finally negotiated.

There's a slight chance that this happens with custom firmware as well, I had this once and wondered why there's suddenly a PIN prompt.

This however doesn't explain why the phone loses connectivity when sleeping. The output of dmesg and logcat in that case would shed light on that. The next time I experience this, I will post a log dump here.

I thought about that too, however the loss of the modem seems to be a hardware or driver issue so I didn't even think that RILd may

be the cause. After all, the stock ROM has these issues as well and doesn't use the open source RIL implementation.

My suspicions circle around:

- wrong clock (would explain the sync. issues)

- weird tegra driver bug

- bug in modem firmware, leaving the modem in a weird state which it can't leave until powered off

To prove that the USB loss is the root cause for the connectivity problem, we could attempt to manually detach the device from the kernel

and see if we still have connectivity. In the case of no connectivity we then know that the device loss is our problem. Otherwise we know that we have a software (e.g. RIL) problem.
[Samsung Captivate Glide] jgilik:
I do see that people are reporting some issues with the stock image, but those issues are dramatically less significant than completely missing the ability to use the radio. To me, the highest priority is to make the radio work, and then we can delve into making it work robustly.

To address your list of suspicions:

Regarding a radio firmware bug: isn't radio firmware what is present in the various .bin files that get dd'ed over to the 7th partition? As in, isn't radio firmware a binary blob that doesn't change betwen the stock ROM and custom ROMs?

Regarding clocks: what are the clock sources in the Captivate Glide? Has anyone gone and labeled all of the chips on the motherboard? If not, it may be time to order a second phone for myself so I have a development phone to take apart and a main phone. I found a teardown here: xdaforums.com/showthread.php?t=740022 It does not seem to identify each chip clearly, though, as they seemed to be concerned with looking for a Bluetooth chip in the hopes of hacking in FM receiver capabilities. If we're going to look for clock sync problems, we're going to have to look for software-controlled clocks i.e. not hardware oscillators, and not clock generators from chips that aren't affected by a ROM update. I'm not opposed to this, but my EE background is considerably weaker than my CS background.

Weird Tegra driver bug: my understanding is that drivers are parts of the kernel, and that the kernel is GPL. If it is a driver bug, then it would mean our kernel source is out of sync with the source used to build the stock AT&T 4.0.4 ICS image. We should contact AT&T and see if we can reconcile the two if this is the case. I'll start work on this path on Monday. I may misunderstand the legalities of the kernel licensing, though... We could rule this out by using the kernel from the stock image as a binary blob. I will look into this as well.

Regarding RILd: I may have misspoken when I said I'd "look into RILd". I'm new to Android, so to me that includes the RIL implementations. RIL appears to be a HAL for radios, so the RIL implementation for the I927's radios may differ in the various open source trees from the AT&T/Samsung trees. I wanted to say that I'd pursue looking into the RIL implementation on the I927.
[Samsung Captivate Glide] Makshow:
I can only answer to this:

I have a big AT&T logo at the top of my phone's front. Never had any issues with baseband on custom ROMs.
[Samsung Captivate Glide] nemo.:
As far as I know, yes. Relevant excerpt from RIL log for loading the firmware:

04-03 15:33:24.314 D/boot ( 6616): <4>cbd: main: Daemon Mode
04-03 15:33:24.314 D/boot ( 6616): <4>cbd: main: EHCI Tegra
04-03 15:33:24.314 D/boot ( 6616): <4>cbd: main: partition number : 7
04-03 15:33:24.314 D/boot ( 6616): <4>cbd: main: partition path : /dev/block/mmcblk0p7
04-03 15:33:24.314 D/boot ( 6616): <4>cbd: main: call boot start
04-03 15:33:24.314 D/boot ( 6616): <4>cbd: start_xmm626x_boot: start

You're right in arguing that the firmware is the same throughout the android distributions. This is probably not the cause.

I experienced a loss of baseband today and searched around for logs. I found the file /data/log/dumpstate_RESET_BY_ITSELF_20140403153324.log with all the important RIL information. The most extraordinary thing that is noticeable is the time warp from 04-04 00:40 to 04-03 15:00:

04-04 00:40:18.419 D/RILJ ( 417): [UNSL]< UNSOL_NITZ_TIME_RECEIVED 14/04/03,14:52:52+08,01,Europe!Berlin
04-04 00:40:18.419 D/RILJ ( 417): [UNSL]< UNSOL_RESPONSE_VOICE_NETWORK_STATE_CHANGED
04-04 00:40:18.419 D/RILJ ( 417): [UNSL]< UNSOL_RESPONSE_VOICE_NETWORK_STATE_CHANGED
04-03 15:01:49.201 D/RILJ ( 417): [UNSL]< UNSOL_NITZ_TIME_RECEIVED 14/04/03,15:00:27+08,01,Europe!Berlin

This looks to me as if the modem queued up time notifications from the provider but didn't hand it to the OS.

As the OS itself worked just fine according to the log (log entry every four minutes or so) I think that the communication or the modem itself was put to sleep somehow (maybe power management issues?).

At least the dev board for the tegra 250 is using the PMU's RTC as provider for the 32kHz clock that is needed:

see here: http://www.manualslib.com/manual/113617/Nvidia-Tegra-Dg-04927-001_v01.html?page=20

They use a TPS658621AZGUR as PMU. Of course, this is unlikely to be the same PMU as the one in the glide but gives us an idea of how the system is supposed to work.

Also ineresting: tegra/clock.c

AFAIK I already tried using a stock kernel to no avail. But you're welcome to try again. I used the instructions bubor kindly gave me back then:
[Samsung Captivate Glide] jgilik:
Thanks for letting us know! Looking around a bit more, I wonder if there are non-AT&T Captivate Glides out there in the world.

Do you know if this firmware contains the RIL client / RIL implementation?

I've read elsewhere in the forum that "you can't use network time, courtesy of AT&T" (paraphrased). Seeing comments along those lines make these lines somewhat interesting.

I'll take a peek when I get CM11 builds set up.

I'll hold off on trying; it's worth taking your word on for the moment. I'll need to get a build set up one way or another to be able to actually fix the issue, so I might as well focus on that before doing particularly advanced diagnostics...

I'll keep you all updated on how it goes. My weekend's starting now-ish, so I'll have some updates by Monday hopefully.
[Samsung Captivate Glide] roothorick:
There are; they were sold by Rogers in Canada. The model code is SGH-I927R but we have no reason to believe there are any hardware differences whatsoever.

There's a few baseband versions, but the ROM zips do not modify the baseband. Generally you'll only get a different baseband if you're flashing with Odin, or deliberately and specifically trying to change the baseband.

It's not a phone limitation; AT&T simply doesn't do network time services on their network. Note the time zone -- "Europe!Berlin". Time zones being what they are, that could also be somewhere in Africa, but either way, he definitely isn't using AT&T. His carrier, whatever it may be, DOES do network time services, so he's receiving time updates from the network.
[Samsung Captivate Glide] nemo.:
Exactly right. The log I posted tells us:

1. my carrier is sending the correct time regularly

2. the modem is receiving the time but not passing it to the OS/RIL when the phone is sleeping

3. after waking by pressing the power button, all queued messages are reported to RIL

The i927 is known for sleeping too deeply and missing calls, messages, etc. so this *might* be a different issue and not connected to the problems with 4.2+ ROMs. What *is* interesting is that the modem is eventually reported as lost. The message queue is processed for some time and then the modem disconnects w/o being reinitialized properly, being stuck in the disconnect/reset/connect loop we're seeing on 4.2+ ROMs as well.

Currently I have two theories why this could be happening:

1. The kernel is, for a time, to busy to maintaining the USB link:

- tegra sleeps deeply, queueing data from interrupts

- tegra wakes up, processes a lot of data uninterruptedly

- tegra loses usb device

2. The usb driver is not using a monotonic clock and is influenced by changing the system time

- tegra sleeps deeply, queueing timing data from interrupts

- tegra wakes up, processes a lot of time data, applying it as it comes

- usb timings are off as time changes

Both of these theories are incomplete, don't explain why the modem can't be re-initialized and are very far fetched (read: I'm guessing).

Edit: Having said that, it would be really interesting how the problem looks with a kernel from current git as there the tegra USB seems to be overhauled as well as power management and PM idle.
[Samsung Captivate Glide] roothorick:
FWIW, the UCLJ3 baseband fixes the modem drop issue... but the phone still deep sleeps. I think the deep sleep problem is an unforseen incompatibility between the Tegra 2 SoC and the modem Samsung used, as it has always been around, going all the way back to the official Gingerbread ROMs.
[Samsung Captivate Glide] nemo.:
I'm currently using UCLJ3. (Kernel 3.1.10-I927UCLJ3 / build IMM76D)
[Samsung Captivate Glide] nemo.:
Since there is not happening a lot regarding this problem, I am currently trying to fiddle with the auto-suspend of USB devices.

/sys/bus/usb/devices/1-1

seems to be modem (1519:0020). Some data on that:

- power/autosuspend_delay is 200ms, to the best of my knowledge this means that the kernel will attempt to suspend that device if it is 'idle' for 200ms.

- power/control is set to auto, which means that the kernel actually enforces power management.

If power management and putting the device idle is the problem with losing baseband because the modem reports faulty idle stats (or something like that) then setting control to 'on' should keep the kernel from suspending the device. I'm currently trying that.
[Samsung Captivate Glide] roothorick:
I don't think this will help you specifically much, but I think you stumbled across a lead for a possible fix to the deep sleep issue...
[Samsung Captivate Glide] steadfasterX:
really? How ? Could you share more of your thoughts regarding that?

Thanks

xdajog
[Samsung Captivate Glide] nemo.:
I actively searched for that fix... And it seems that it indeed fixes the deep sleep issue. However, battery life is reduced significantly (several days vs. approx. ~1.5 days). I tested this with

echo on > /sys/bus/usb/devices/usb1/power/control

echo on > /sys/bus/usb/devices/1-1/power/control

Is the signal loss issue limited to a small group of captivate glide users as well?
[Samsung Captivate Glide] steadfasterX:
have you done any tests setting the autosuspend_delay_ms to a high value instead of totally disable control? May not help but if so it would be better than to avoid suspending in general..
[Samsung Captivate Glide] nemo.:
autosuspend_delay_ms is the time in milliseconds for how long the device needs to be idle before it is suspended by the kernel. If the problem is that the device fails to reactivate itself, then this parameter would not help at all since the chance of the modem disappearing is only reduced, not eliminated. So, no I haven't tested it.

It would be very helpful we were able to reproduce the behaviour of the modem after a failed re-initialization since the problem at boot-time for 4.3 ROMs and the problem after failed suspend on stock firmware look essentially the same. In both cases the modem fails to negotiate an USB high-speed connection.
[Samsung Captivate Glide] panama.hill:
same here -- baseband loss

Same here -- cannot flash any custom ROM without baseband loss on my AT&T Capti. I have tried all the http://dualhoki.vim.hu/bubor/dev/modem/ replacements, permissions, /efs, etc. and nothing works (I just tested omni-4.4.4-20141223-i927-HOMEMADE.zip as well). On my stock 4.0.4 ROM, I occasionally lose baseband, as others do. As ICS ages, upgrading to 4.2 or 4.4 is becoming more important.

This is my first post on XDA, so my apologies in advance if I am incorrect.
[Samsung Captivate Glide] bubor:
you can try upgrade bootloader ( see dev forum)
[Samsung Captivate Glide] nemo.:
You mean this thread? http://xdaforums.com/captivate-glide/development/update-bootloader-to-t2988425

Can you fiddle around with the phone after flashing the new ROM and see whether the modem gets connected at some point in time? I experienced this once with the custom 4.2 ROM but I could not figure out what triggered the modem to finally initialize the USB connection successfully. Maybe we will get some information about what triggers the bug in the first place.

It would also be interesting whether we have a different modem revision or something. Can you post the output of

lsusb -v

from a shell on the phone?
[Samsung Captivate Glide] panama.hill:
lsusb -v output:

Bus 001 Device 001: ID 1d6b:0002

Bus 001 Device 002: ID 1519:0020

I will try to updated bootloader as suggested. The instructions in that thread have me a little confused ("run browse bootloader"), and I am searching how to backup the bootloader first.
[Samsung Captivate Glide] nemo.:
Oh, btw. do you see

usb 1-1: device descriptor read/64, error -110

in the output of the dmesg command as well when the modem fails to initialize?

It may very well be that we deal with a power issue which may be caused by a faulty capacitor...
[Samsung Captivate Glide] panama.hill:
Not the exact same, I get:

<6>[ 107.346237] hub 1-0:1.0: USB hub found

<3>[ 107.396525] tegra_usb_phy_bus_connect: timeout waiting for hsic connect detect

<6>[ 107.594719] tegra_usb_phy_bus_reset

<6>[ 107.599820] tegra_usb_phy_bus_reset:4:USBMODE:3 USBCMD:10005 USBPORTSC1:8001205 USBSTS:80

<6>[ 107.714646] usb 1-1: new high speed USB device number 2 using tegra-ehci

<3>[ 108.134733] usb 1-1: device not accepting address 2, error -71

... after a few more resets ...

<3>[ 111.065688] usb 1-1: device descriptor read/64, error -71

The above is after updating the bootloader and flashing the omni-4.4.4-20141223-i927-HOMEMADE.zip The only error message I received was when wiping, "E:Unable to mount '/preload'"

After the first boot of the omni rom, after a few minutes, I did actually get actually get bars and could make a call. Then the phone went back to the usual baseband unknown. I have tried multiple times pulling battery and rebooting, etc., to no avail. I am uncertain how else I might fiddle with it.
[Samsung Captivate Glide] nemo.:
So, to recapitulate what we have found out about this bug:

- Independent of brand (AT&T / Rogers)

- Affects a small subset of these phones

- 2.3.x using Linux Kernel 2.6.36.x is fine

- 4.0.4 using Linux Kernel 3.1.10 is sometimes causing trouble

- 4.x using newer Linux Kernel versions than 3.1.10 is always causing trouble

- Swapping boot loader does not help

- Sometimes reported: usb 1-1: device descriptor read/64, error -110 ("Not enough power for device")

- Frequently reported: usb 1-1: device descriptor read/64, error -71 ("EPROTO / USB protocol error")

All this looks to me like a hardware issue which surfaced due to changes in the tegra EHCI driver because someone tweaked timings or the EHCI now employs a more strict HSIC negotiation.

Ideas:

- Port the Linux 2.6.3 tegra EHCI code to newer kernels (possibly a lot of work, not guaranteed to work)

- Debug USB wiring / capacitors from USB hub to modem

- ???

Does anyone has access to the service manual or schematics of the Captivate Glide?
[Samsung Captivate Glide] bubor:
imho, just buy another phone.
[Samsung Captivate Glide] panama.hill:
Anyone know the odds of buying another one with the same problem?
[Samsung Captivate Glide] bubor:
just dont buy i927 ;)
[Samsung Captivate Glide] Adam77Root:
Don't buy any Tegra device, they all have the same problem.
[Samsung Captivate Glide] nemo.:
This does not sound right. The specific problem described in this thread seems to occur for only a minority of the people. What problem do you speak of?
[Samsung Captivate Glide] Adam77Root:
Baseband stuff in general. The modem is an internal USB device on the Tegra platform (on 2 and 3 for sure, don't know about others, but guess the same as the chipset is originally for tablets and therefore does not have a built-in modem). Most of the people have no issues. As far as I read threads, it mainly depends on carrier and/or the network infrastructure it provides. I personally never had any modem issues neither with my Samsung Galaxy R (Tegra 2) nor LG Optimus 4X HD (Tegra 3).

On the SGR, people have been reporting dead call issues (other party hears phone ringing, but it doesn't ring) and SMS/MMS messages arrived only when screen got unlocked. Basically, when the device was in deep sleep, all modem communication stopped. Both on stock and on custom roms. I never had a single lost call or text.

On the O4X, modem loses connection repeatedly, CP (communication processor) crashes and needs hard reset, SIM PIN get re-asked many times. Basically, the whole RIL stack crashes sometimes. Again, I never had any crash at all and there are others as well who also didn't have. Other users have all these sorts of issues, mainly on custom roms. In stock rom, LG has implemented a RIL recovery mechanism that force restarts needed stuff (just the RIL daemon, CP or even the internal modem USB power driver sometimes, depending on state and crash count). When this happens, the phone is not usable as a phone for a short while.

I didn't do much investigation regarding this problem as it never affected me, but others did and it's caused on both devices by essentially the same thing, namely the USB-based modem implementation. This is in no way a normal behaviour, the modem should be directly connected to the chipset as it's a vital thing and the Tegra platform is among the (very) few where it isn't.
[Samsung Captivate Glide] nemo.:
Ah that is very nice to know. Some time ago I did a little research if other Tegra devices experienced this bug as well but I did not find anything useful. This really sounds like a software / protocol / timing bug then. Another possibility is that the modem does not follow the USB specification correctly (which has happened surprisingly often with various USB devices).

Do you know whether there were attempts to fiddle with the Tegra EHCI code?

EDIT:

Some USB modems are prone to errors in combination with USB hubs when the device gets suspended. To quote http://lists.apple.com/archives/usb/2004/Mar/msg00039.html: "Some USB CDC modems handle this request properly, others do not. Anyway, once the device is suspended, there is a problem in resuming the device which occurs when the bus topology is that the bus powered modem is connected across a USB hub.".

Also a list of devices using the same modem according to USB vendor/product ID "1519:0020":

- Galaxy SII GT-I9100 (http://xdaforums.com/showthread.php?t=1181222)

- Galaxy Note GT-7000 (http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=6&t=1348)

The modem with this ID is used in product such as:

- Telit HE863 (https://community.freescale.com/thread/294555)

- AMOD ACE9000 (http://module.amod.com.tw/files/Product/20117793736.pdf)

There seem to be timing workarounds for this modem in the XMMS tegra code: https://android.googlesource.com/ke.../arch/arm/mach-tegra/baseband-xmm-power.c#312

The enum_delay is a module parameter set to 1000 msecs by default. It would be interesting to know if this parameter can be tweaked at runtime.
[Samsung Captivate Glide] cristihan:
Thanks AndyYan, that has solved the problem of my Samsung Galaxy S2 (GT-i9100) on CM12.1-SNAPSHOT :good: