17.22.46 - real full changelog

[deonb]

Root your Tesla???... what a gutsy move...

It's sad that taking control over your own property is a gutsy move. (I agree that it is... it's just sad that it is).

 

[verygreen]

The bug() function means that if you put the /proc/printk log level of the kernel higher than it is set now, you get more output. If you never use this functionality, removing this option as suggested makes the kernel smaller. It has nothing to do with crashing earlier. It's a suggested optimisation (with a downside), so if the kernel loglevel is sometimes set higher, it's not a good recommendation.

I think there's a bit of misunderstanding here.
BUG() function is a fancy wrapper around panic(), there's no continuation after the call:

/*
 * Don't use BUG() or BUG_ON() unless there's really no way out; one
 * example might be detecting data structure corruption in the middle
 * of an operation that can't be backed out of.  If the (sub)system
 * can somehow continue operating, perhaps with reduced functionality,
 * it's probably not BUG-worthy.
 *
 * If you're tempted to BUG(), think again:  is completely giving up
 * really the *only* solution?  There are usually better options, where
 * users don't need to reboot ASAP and can mostly shut down cleanly.
 */
#ifndef HAVE_ARCH_BUG
#define BUG() do { \
        printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, __func__); \
        panic("BUG!"); \
} while (0)
#endif

As for the aslr, I just took a closer look and they enable it from sysctl:

# cat rd/etc/sysctl.d/10-full-aslr.conf
# Enable all ASLR capabilities
kernel.randomize_va_space = 2

Now all that's needed is for them to release the source so we can fix all of the (perceived) problems

 

[bmah]

It's sad that taking control over your own property is a gutsy move. (I agree that it is... it's just sad that it is).

I think you're referring to the hoops that one has to jump through to get root access. IMHO even if Tesla handed out superuser privileges to anyone that asked, it's still pretty gutsy to even want to muck around with root-level access on the innards of a car. (It's not like spinning up a scratch VM that you can just blow away if you mess it up.)

I used to build Linux-based appliances, and I find this discussion fascinating!

Bruce.

 

[verygreen]

even if Tesla handed out superuser privileges

I believe if you pay for the toolbox subscription (and located in MA) the tools provide you with root access too. Or used to provide, anyway.

It's not like spinning up a scratch VM that you can just blow away if you mess it up

If you break the stuff bad enough, there's a recovery mode (similar to android), also similar to new Androids and ChromeOS, there are two copies of binaries, the "old" and "new" ones, and they are in readonly filesystems.
The only vulnerable part is where passwords and logs are stored, mostly (also the vpn keys, but there's a separate copy to that).
So you basically have 3-4 targets to boot from at any time, wiping all of them requires some effort.

In this regard rooting the car is not too much different from rooting your phone (other than the price, I guess).

 

[brianman]

In this regard rooting the car is not too much different from rooting your phone (other than the price, I guess).

... and that phones are not regularly projectiles.

 

[deonb]

... and that phones are not regularly projectiles.

And the part of the system that makes the car a projectile or not isn't based on what's effectively a glorified car radio.

I'm sure you've rebooted both of your computers while driving before without concern that the car would become uncontrollable.

 

[TJtv]

Rebooted both of the computers while driving? Do people really do that? I would never in a million years attempt something like that.

 

[verygreen]

Rebooted both of the computers while driving? Do people really do that? I would never in a million years attempt something like that.

Car does it for you.
I had cid crash as I was driving today (yay new kernel?!), it's annoying that the A/C stops working until it finishes the rebooting.

 

[lunitiks]

it's annoying that the A/C stops working until it finishes the rebooting.

word

 

[Fingerz]

So I took a look into the full 17.22.46 changelog, and it's interesting.

For whatever reason Korea got a different header. Where's with all other countries we have the typical "With this release, we're continuing to improve your...", Koreans get "Welcome to your new Model S/X!"

For HONG KONG AND MACAO for whatever reason there's a whole section about enabling autosteer (beta), was not that enabled like mid-March over there anyway?

Same for lane change and parallel park. But this section is not shown in Taiwan.

Perpendicular parking: we know we saw it, but it's not shown in Korea or Taiwan.

Updated Web Browser: - nobody saw this ever, because it's marked as "hidden".


Updated Energy Estimation: Only for S/X 100D and X 60D, but not shown in North America and Korea:


Top Tether Position for Child Safety Seats: tihs is only shown for Model X without "easy entry" whatever that is.


Display Brightness - everybody will see this, but only on HW2 cars.

Did you see anything specific to the United Arab Emirates or the Middle East? Word is that Autosteer has been disabled for AP2 cars with this release in the UAE.

 

[verygreen]

Did you see anything specific to the United Arab Emirates or the Middle East? Word is that Autosteer has been disabled for AP2 cars with this release in the UAE.

No mentions of uae or arab-anything in any way.
If it was just one report, possibly it's just a crashed ape that needs to be reset? (i.e. is it just autosteer that's not working, or speed limit not showing too and such)

 

[wesley888]

Car does it for you.
I had cid crash as I was driving today (yay new kernel?!), it's annoying that the A/C stops working until it finishes the rebooting.

Yeap. Been there. Done that. My wife got a bit scared when the screens went black and A/C went off. But we could still drive normally.

 

[thimel]

Rebooted both of the computers while driving? Do people really do that? I would never in a million years attempt something like that.

Yes, I and others have done it and it is safe.

 

[jnuyens]

I think there's a bit of misunderstanding here.
BUG() function is a fancy wrapper around panic(), there's no continuation after the call:
Now all that's needed is for them to release the source so we can fix all of the (perceived) problems

True, there is some misunderstanding, I was talking about configuration options in the kernel:
CONFIG_BUG: │
│ │
│ Disabling this option eliminates support for BUG and WARN, reducing │
│ the size of your kernel image and potentially quietly ignoring │
│ numerous fatal conditions. You should only consider disabling this │
│ option for embedded systems with no facilities for reporting errors. │
│ Just say Y.

My point was that if the kernel log level isn't set higher, these messages are ignored anyway and the kernel can be smaller. Not necessarily a good point, as they might want to increase loglevel in certain cases (but in that case they could also opt for a completely logging and debugging enabled kernel (including for example the basic locking checks and such, and perhaps kgdb).

Grtz!
Jasper

 

[vandacca]

Does anyone know if there is any Real-Time implementation in this version of Linux. Something like QNX?

 

[gearchruncher]

Does anyone know if there is any Real-Time implementation in this version of Linux. Something like QNX?

It's not doing anything real-time, so why bother? This isn't code that manages the drivetrain or AP.

 

[jnuyens]

It's not doing anything real-time, so why bother? This isn't code that manages the drivetrain or AP.

Verygreen clearly has more knowledge about what's on the car than me - I still have to (try to) look.
But the kernel config he posted did not point to any realtime patches nor xenomai.
The realtime patches might make the UI a little bit less laggy.

But as gearchruncher indicated, there is no 'hard realtime' need for this part of the car.

 

[brianman]

Rebooted both of the computers while driving? Do people really do that? I would never in a million years attempt something like that.

Rebooted both screens with travelling at highway speeds on (TA)CC, yes. But that may or may not be what you're asking.

 

[verygreen]

True, there is some misunderstanding, I was talking about configuration options in the kernel:
CONFIG_BUG: │
│ │
│ Disabling this option eliminates support for BUG and WARN, reducing │
│ the size of your kernel image and potentially quietly ignoring │
│ numerous fatal conditions. You should only consider disabling this │
│ option for embedded systems with no facilities for reporting errors. │
│ Just say Y.

My point was that if the kernel log level isn't set higher, these messages are ignored anyway and the kernel can be smaller. Not necessarily a good point, as they might want to increase loglevel in certain cases (but in that case they could also opt for a completely logging and debugging enabled kernel (including for example the basic locking checks and such, and perhaps kgdb).

They have a facility to capture kernel panic logs from ramconsole or whatever the new fancy name is, I believe, very android-like.
Additionally if you disable this option, it turns BUG() into:

#else /* !CONFIG_BUG */
#ifndef HAVE_ARCH_BUG
#define BUG() do {} while (1)
#endif

This is obviously waay inferior in comparison to panic(), since in case of the panic not only you get a sensible message to know what happened, you also can setup "reboot on panic" timeout instead of hanging there forever and requiring user interaction to reboot.

The WARN() is just a message, BUT even then you can turn on panic_on_warn (not that Tesla does it), but more importantly, all those
messages do get into logs and Tesla does collect the logs proatively (like all the time) so those messages (at leat potentially) could be put to a good use. It's not like there's a drastic memory shortage on those nodes to save a hundred kb or so.

 

[verygreen]

It's been real boring without my car using the non-AP S loaner for the last 2.5 weeks, so I dug a bit and found how to get ape2 firmware even without AP2-enabled car.
It seems model-wise all the neural net stuff is the same in 17.22.46 with 17.17.4, but there are some other goodies (probably in preparation?)
We've got:
* rain_light_sensing - self explanatory, I hope
* atlas - this seems to be some sort of map-aware thingie, loaded with fremont map tile for now.
* determinator - I am not really sure what it does yet, seems to be listening to can traffic in particular, also determines vehicle config apparently.
* driver_monitor - this like what it says seems to be logging info about the driver, when last detected and what actions were taken and such presumably for inclusion into the logging
* imu - has all sort of accelerometer references, so must be positioning enhancing based on those I imagine? "localization sensors" is how it's referred to in another place. It seems to supersede inertiator task (binary is still there but is not used).

Also a lot more model 3 references in the code now compared to 17.17.4 too.

Now, Tesla, hurry up and fix up my car before I discovered everything about 0281608a7bab99dac59baf5a5c4281a8469e607777115b21b07d508c6692364c