Let's talk about safety of Pinephone(xnux.eu)
xnux.eu
Let's talk about safety of Pinephone
https://xnux.eu/log/#017
78 comments
It doesn't matter.
There should be nothing an end user can do without disassembling the phone that can make it catch fire. If there is, then someone will do it. And personally, I wouldn't think twice about connecting the HDMI without connecting the power, for five minutes, to get hold of some document.
I don't own a Pinephone, and from the looks of this debacle I never will. It doesn't seem that OSS is safe to run in safety-critical contexts.
There should be nothing an end user can do without disassembling the phone that can make it catch fire. If there is, then someone will do it. And personally, I wouldn't think twice about connecting the HDMI without connecting the power, for five minutes, to get hold of some document.
I don't own a Pinephone, and from the looks of this debacle I never will. It doesn't seem that OSS is safe to run in safety-critical contexts.
> I don't own a Pinephone, and from the looks of this debacle I never will. It doesn't seem that OSS is safe to run in safety-critical contexts.
Sound rather limited, almost stupid.
OSS runs in various safety critical software, FreeRTOS, also Linux and various other projects run in very critical environments, far more critical than a smartphone.
https://scholar.google.at/scholar?q=open+source+software+in+... https://scholar.google.at/scholar?q=linux+in+safety-critical...
You know that something is OSS allows letting anybody check this out in the first place, do you really think a proprietary phone is safe from this? There are many reports about iPhones and other smart phones catching fire each year.
Sound rather limited, almost stupid.
OSS runs in various safety critical software, FreeRTOS, also Linux and various other projects run in very critical environments, far more critical than a smartphone.
https://scholar.google.at/scholar?q=open+source+software+in+... https://scholar.google.at/scholar?q=linux+in+safety-critical...
You know that something is OSS allows letting anybody check this out in the first place, do you really think a proprietary phone is safe from this? There are many reports about iPhones and other smart phones catching fire each year.
If the HDMI doesn’t work unless the dock is plugged in, then it absolutely does matter.
https://news.ycombinator.com/item?id=24599735
https://news.ycombinator.com/item?id=24599735
That's pretty standard if you have a HDMI dongle that doesn't also provide power supply. Of course people do that and HW needs to handle it.
Yes, I did not get my dock to work with my monitor without even plugging the dock into power.
Oh I managed to misread the title, and was wondering how the common fruit can be so dangerous
I've to admit I'm surprised that the battery management is not on a separate IC. While quite a few battery management decisions are better done by software, hard-limits on current/temp/discharge really are not.
Am I misinterpreting this?
Am I misinterpreting this?
I don’t know what battery pinephones source, but I am under the impression that all smartphone batteries have a battery management IC that handles safety hard limits internally. Lithium ion inherently needs a lot of care in charging and discharging. You can get lithium ion batteries without smarts attached for RC planes and cars, but those are known to catch fire often since they’re driven so hard :).
These battery management ICs will permanently shut down the battery off above a dangerous temperature threshold. Better to kill a battery than to risk a fire.
These battery management ICs will permanently shut down the battery off above a dangerous temperature threshold. Better to kill a battery than to risk a fire.
> I don’t know what battery pinephones source
From the Pinephone wiki: "Battery: Lithium-ion, rated capacity 2800mAh (10.64Wh), typical capacity 3000mAh (11.40Wh) (nominally replaceable with any Samsung J7 form-factor battery)"
I guess they're sourcing unmarked Samsung compatible batteries which should be all protected, where should equals to 99.999%.
If that's the case, then there's no way malicious software or even firmware could damage it. The protection in those batteries is implemented hardware level; the chip contained in the cell will cut off its connection if it detects either an excessive discharge current (to avoid potential explosion), excessive voltage discharge (to avoid chemical degradation and subsequent charging attempts related dangers), excessive temperature (again to avoid explosion), excessive charging current (... explosion). They are all detected outside of system control, so no need for panic.
From the Pinephone wiki: "Battery: Lithium-ion, rated capacity 2800mAh (10.64Wh), typical capacity 3000mAh (11.40Wh) (nominally replaceable with any Samsung J7 form-factor battery)"
I guess they're sourcing unmarked Samsung compatible batteries which should be all protected, where should equals to 99.999%.
If that's the case, then there's no way malicious software or even firmware could damage it. The protection in those batteries is implemented hardware level; the chip contained in the cell will cut off its connection if it detects either an excessive discharge current (to avoid potential explosion), excessive voltage discharge (to avoid chemical degradation and subsequent charging attempts related dangers), excessive temperature (again to avoid explosion), excessive charging current (... explosion). They are all detected outside of system control, so no need for panic.
Define excessive discharge. In-battery circuit kicks in at 6-8A. Battery is specced for max 1.4A continuous charge/discharge current. With the safety margins in these things, it will probably take 2-3A continuously, too. But can it take 4A for 1 hour? Wanna try?
Also, there's no protection against excessive temperature in the battery protection circuit's specification, so not sure where you're taking your information from. It would be nice if people actually used the datasheets that are freely available, since Pinephone is mostly open HW, instead of proclaiming random generalities.
Also, there's no protection against excessive temperature in the battery protection circuit's specification, so not sure where you're taking your information from. It would be nice if people actually used the datasheets that are freely available, since Pinephone is mostly open HW, instead of proclaiming random generalities.
Those chips on the packs are last resort safety, not something to be relied upon daily as charge controllers.
Certainly not. That is what the PMIC is for. It’s up to the developers to responsibly configure the PMIC and that is a real hazard. However, the safety situation might not be as bad the author makes it out to be. I don’t know any better though, and it is always a good idea to know when it comes to safety. It’s an important topic to shine the light on.
The author also mentions LCD damage from SoC heat. Could it lead to a runaway from that side?
Last time I read about PinePhone, the topic was kill switches hardwired to chip enable pins that also make it impossible to sleep peripherals from main SoC. That was only “weird but okay”, but personally, with this discussions going, this phone and associated ROMs aren’t something I consider anymore.
Last time I read about PinePhone, the topic was kill switches hardwired to chip enable pins that also make it impossible to sleep peripherals from main SoC. That was only “weird but okay”, but personally, with this discussions going, this phone and associated ROMs aren’t something I consider anymore.
For RC cars/aircraft etc those are usually incredibly high current LiPo chemistry and wired in series to deliver much higher voltage. The LiIon chemistry used in electronics on the other hand is quite pedestrian and packs are constructed with lower peak current and voltage output.
Despite similarity in name they are very different beasts. I'm not all that afraid of a LiIon pack unless it's been sorely mistreated or is a huge EV pack or something. On the other hand I treat LiPos with the utmost respect and get them far away from anything at the first sign of bloating or accidental shorting.
Despite similarity in name they are very different beasts. I'm not all that afraid of a LiIon pack unless it's been sorely mistreated or is a huge EV pack or something. On the other hand I treat LiPos with the utmost respect and get them far away from anything at the first sign of bloating or accidental shorting.
Yeah, getting your wire cutter arc-welded to the cable because you accidentally touched it to both ends of a LiPo is... fun.
I would love to see a write-up and pictures of that incident. I think a lot of people, probably myself included, don't always give them the respect they deserve, and that would be a really neat story/visual to drive the point home.
Obviously, no pressure, but figured I'd express the interest
Obviously, no pressure, but figured I'd express the interest
It's much less interesting than it sounds, I was cutting the connector off to solder on a new one, and the first wire accidentally touched for a moment while I was cutting the second one. There was a huge spark and a big mark on the cutter.
That's usually the case in the battery packs. Looks like I'll be ripping apart my battery when I get around to taking out the Pinephone.
> Lithium ion inherently needs a lot of care in charging and discharging.
For longevity this is true, but even the while overcharging the risk of a fire isn't that high nowadays (from what I've seen close to 0 with cylindrical cells). Some pouch cells are even fine when punctured.
Of course I want these issues to be fixed to keep Pinephones working and AFAIK the batteries in the Pinephone are of an older model, so maybe they're a bit more dangerous. The author definitely has a point.
For longevity this is true, but even the while overcharging the risk of a fire isn't that high nowadays (from what I've seen close to 0 with cylindrical cells). Some pouch cells are even fine when punctured.
Of course I want these issues to be fixed to keep Pinephones working and AFAIK the batteries in the Pinephone are of an older model, so maybe they're a bit more dangerous. The author definitely has a point.
I for one, would like batteries without built-in IC as we can run the device with external power even after the battery has died, with the battery removed, older phones/tablets where capable of being used with external power with a trivial hack.
With current generation devices, once the battery is dead, it requires replacement even to use the device for an application which has constant power supply(e.g. external monitor), especially if it has become a spicy pillow and constant power supply means it can again become a spicy pillow[1].
[1]https://twitter.com/heavyinfo/status/1302310594423345152?s=2...
With current generation devices, once the battery is dead, it requires replacement even to use the device for an application which has constant power supply(e.g. external monitor), especially if it has become a spicy pillow and constant power supply means it can again become a spicy pillow[1].
[1]https://twitter.com/heavyinfo/status/1302310594423345152?s=2...
These two things are not mutually exclusive. The decision to allow operating without a battery is a mainboard design decision and has very little to do with the protection circuitry on the battery pack. In a device like this, the decision to require the battery as the primary current source is usually due to the high current draw for activities like initial searching for a cell tower. Lithium batteries can source this current easily, but if you want to run without the battery, your charger needs to be able to source that max current as well. Sizing the charger to handle this brief load translates directly to additional product cost, so it is often not done that way.
The protection circuitry on the battery pack is designed to protect the cell from charging and discharging situations that may damage the battery. You definitely want those protections in there.
The protection circuitry on the battery pack is designed to protect the cell from charging and discharging situations that may damage the battery. You definitely want those protections in there.
There is virtually no batteries without ICs, and, that has nothing to do with whether the device runs without a battery. That’s just a design choice.
>There is virtually no batteries without ICs
There are after market batteries w/o battery management ICs like TI Gas Gauge, its up to device on whether it will accept a battery without such IC.
>that has nothing to do with whether the device runs without a battery. That’s just a design choice
I agree that just having a battery without IC doesn't guarantee that the device would function directly with an external voltage regulated power supply, but a device which accepts only the battery with specific IC makes it difficult or even impossible to run the device that way.
There are after market batteries w/o battery management ICs like TI Gas Gauge, its up to device on whether it will accept a battery without such IC.
>that has nothing to do with whether the device runs without a battery. That’s just a design choice
I agree that just having a battery without IC doesn't guarantee that the device would function directly with an external voltage regulated power supply, but a device which accepts only the battery with specific IC makes it difficult or even impossible to run the device that way.
It is separate IC: AXP803
It sounds like Pine should at least issue guidance around these specs for distro devs, even if they don't participate in actually writing the software or configuring the kernel.
I think most distros currently pull from the pine64 kernel repo. There's the end goal of merging things into mainline but lots of bugs are getting fixed quickly so it's a ways off.
Seems to me that main difference is that with PinePhone and FLOSS we can see such issue. It is hard to say how many non-free phones have similar hacks. Considering the usual state of embedded software, i would guess that many.
Are there safety regulations or certifications for this? If so do smartphones usually pass them and does PinePhone pass them?
There are an enormous number of regulations around this, if you look at all the regulatory markings on most electronics. UL and Intertek being the biggest ones for electrical safety. I really hope Pine64 has gotten those certifications.
AFAIK one of the reasons phones typically leave logic like this in a binary blob on an IC is because the certification bodies stipulate that not only does a device have to comply with safety standards, but it can't be trivially modifiable by an end-user to violate those standards.
If you're marketing a phone where one of the advertised features is the ability to change the operating system, and the operating system is responsible for enforcing electrical safety, i don't really see how that's certifiable.
If you're marketing a phone where one of the advertised features is the ability to change the operating system, and the operating system is responsible for enforcing electrical safety, i don't really see how that's certifiable.
That's usually for radio emissions, not for stuff like thermals.
Radios are much more regulated.
Radios are much more regulated.
This is the Pinephone's CE certificate:
http://files.pine64.org/doc/cert/PinePhone%20CE%20RED%20Cert...
Would be fun to see what of those articles are safety related, and what do testers test for actually.
http://files.pine64.org/doc/cert/PinePhone%20CE%20RED%20Cert...
Would be fun to see what of those articles are safety related, and what do testers test for actually.
I wonder, if pinephone were to sell a version that was an ikea-style assemble-it-yourself kit, would that still require those certifications?
CE and CCC are the most important as they cover Europe and China.
Really? The article's author pet peeve is that all software running on PinePhone start with "no guarantee" or "as is". Tell me, does Apple or Samsung or Microsoft take responsibilities for their shitty software? Because so far I've seen thousands of examples their software bricking / penetrated / ransom-ware etc, and not a single one of them was held accountable in court of law because of that. Apple is the most vertical company, heck they give their software for free and even that one doesn't come with guarantees.
> The article's author pet peeve is that all software running on PinePhone start with "no guarantee" or "as is".
Not really. It's not even that it's a pet peeve, just them pointing out that projects need to keep safety in mind.
The author even mentions that they have contributed to PinePhone software.
Not really. It's not even that it's a pet peeve, just them pointing out that projects need to keep safety in mind.
The author even mentions that they have contributed to PinePhone software.
The issue is they're heavily implying it's something specific to PinePhone. I just scrolled through the legal notices on an iPhone, and they all have the exact same wording.
Small components, such as the graphics libraries, the kernel, health data, the web browser, etc...
(not to mention they're just plain wrong about the battery/thermal not having hardware-level limits)
(not to mention they're just plain wrong about the battery/thermal not having hardware-level limits)
The actual end product is provided by Apple with no warranties? I find that hard to believe. It makes sense that the OSS libraries they use wouldn't have warranties provided by their developers, but an issue in any of those becomes an Apple issue when it's shipped in their product as long as the issue has an impact on iOS.
I believe so, at least on the software side. For example, the macOS EULA states:
> C. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE APPLE SOFTWARE AND SERVICES ARE PROVIDED “AS IS” AND “AS AVAILABLE”, WITH ALL FAULTS AND WITHOUT WARRANTY OF ANY KIND
https://www.apple.com/legal/sla/docs/macOSCatalina.pdf
> C. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE APPLE SOFTWARE AND SERVICES ARE PROVIDED “AS IS” AND “AS AVAILABLE”, WITH ALL FAULTS AND WITHOUT WARRANTY OF ANY KIND
https://www.apple.com/legal/sla/docs/macOSCatalina.pdf
Sorry, but you're just plain wrong. So please don't spread false sense of security if you don't understand the issues, or the HW. You can read my other comments in this HN comment section for why.
It doesn't read to me that the author is stating it's specific to pinephone, I read it as them just saying "hey guys, look out for this."
If they use the license wording to help get it across, well, I don't necessarily agree but as they state in the article:
> I'm trying to be a bit inflamatory here, to start the conversation.
If they use the license wording to help get it across, well, I don't necessarily agree but as they state in the article:
> I'm trying to be a bit inflamatory here, to start the conversation.
If the conversation is
> Software engineering does not put safety first
I'm 100% agreed.
If the conversation is
> The PinePhone has less quality control than Android/iOS
It's patently false
I would parse the article as the second, as it's referring to a specific phone throughout
> Software engineering does not put safety first
I'm 100% agreed.
If the conversation is
> The PinePhone has less quality control than Android/iOS
It's patently false
I would parse the article as the second, as it's referring to a specific phone throughout
I read it as the first, with a side of "We need to do this or FL/OSS hardware is going to look bad".
And I concur about the second being patently false. I would guess that it has more overall tbh.
And I concur about the second being patently false. I would guess that it has more overall tbh.
>> The PinePhone has less quality control than Android/iOS
> It's patently false
PinePhone is just HW. Android/iOS is SW. Comparison doesn't make sense. Maybe compare PinePhone to Huawei Honor, or Xiaomi and their HW testing:
https://www.youtube.com/watch?v=tvRTY6sBPeE
> It's patently false
PinePhone is just HW. Android/iOS is SW. Comparison doesn't make sense. Maybe compare PinePhone to Huawei Honor, or Xiaomi and their HW testing:
https://www.youtube.com/watch?v=tvRTY6sBPeE
> It's patently false
That's a strawman: author never compared to Android/iOS. What they did spell out,is that some of the code they found is unsafe (e.g. commented-out code to prevent false alerts, that was never being reimplemented in a safer way).
That's a strawman: author never compared to Android/iOS. What they did spell out,is that some of the code they found is unsafe (e.g. commented-out code to prevent false alerts, that was never being reimplemented in a safer way).
But the article does not mention that other phones might have similar challenges. If the article is about the whole industry then say that, if it is specific to the pinephone say that. Currently it's in that weird middle zone where it sounds like it is specific but all the facts would probably be applicable to many phones.
In particular the author maintains a kernel branch that is very advanced. Only a few projects use it though, and I once asked for why that was and was told that many patches in that authors kernel branch were unlikely to ever be mainlined and thus would not fit the approach of the distribution.
That's not very precise. :) Many of my patches from my kernel get pulled to "pine64" kernel, including those that are not mainlinable. Distros that care about mainline just use Linus's tree already.
There are not many reasons not to use my kernel tree for Pinephone. I actually had reports from users that my multi-distro image that uses my kernel for 13 different pinephone distributions makes some distros run better.
I suspect that distro maintainers just think that pine64 community gitlab is somehow more official than any other pinephone kernel developer's tree on the internet, just from the name.
There are not many reasons not to use my kernel tree for Pinephone. I actually had reports from users that my multi-distro image that uses my kernel for 13 different pinephone distributions makes some distros run better.
I suspect that distro maintainers just think that pine64 community gitlab is somehow more official than any other pinephone kernel developer's tree on the internet, just from the name.
Sorry if I misrepresented things.
After giving Purism some money for their "Fund Your App"-thingy today I decided to hit your donation button with a small, but recurring donation, because you deserve it for all your work – even if, sadly, my favourite distribution (DanctNIX Mobile) does not use your kernel and I am too lazy to change that on my end.
After giving Purism some money for their "Fund Your App"-thingy today I decided to hit your donation button with a small, but recurring donation, because you deserve it for all your work – even if, sadly, my favourite distribution (DanctNIX Mobile) does not use your kernel and I am too lazy to change that on my end.
Not a single software ever written comes with guarantees. And the way he was phrasing sounded like PinePhone is a hot potato while everybody else is chill, while in reality everybody's the same in that regard.
It doesn't read to me that the author is stating it's a hot potato, I read it as them just saying "hey guys, look out for this."
Consumer protection laws nevertheless hold manufacturers liable. Small part of why doing hardware is hard.
Would that be the manufacturer of the software or of the hardware? I don't think any court would blame manufacturers for incidents caused by user-modifications (installing 3rd-party firmware)
We aren’t talking about malware. We are literally talking about software that can cause your phone to explode. Would you trust Apple to do more safety testing or random open source contributors? The article says that safety measures at the firmware chip level are disabled.
> The article says that safety measures at the firmware chip level are disabled.
Those are the safety measures protecting the PMIC, not the battery. Is that temperature cutoff even low enough to matter before the battery is on fire?
It isn't clear that the software protections ever mattered anyway. If the kernel crashes, or is just charging while turned off, I sure hope it's still designed to be completely safe, and not a sudden explosion risk.
Those are the safety measures protecting the PMIC, not the battery. Is that temperature cutoff even low enough to matter before the battery is on fire?
It isn't clear that the software protections ever mattered anyway. If the kernel crashes, or is just charging while turned off, I sure hope it's still designed to be completely safe, and not a sudden explosion risk.
No, those are protections that kernel/bootloader need to configure inside PMIC (instead of disabling them, or leaving them at wrong default values) and then PMIC will protect the battery from overheating from charging. (which is one of many sources of heat) PMIC can also send interrupt to SoC when this control loop fails, and OS is free to handle it in some other way (for example by initiating normal system shutdown)
Then PMIC operates independently from the kernel, and configuration even persists when powered off/during reboots.
HW is designed to be safe, but SW has to cooperate, including userspace. (some daemon that will help policing the whole device, based on many different inputs and by controling things that affect heat production - like preventing the user from setting backlight at max, limiting modem RF output to something that doesn't need huge amounts of power, etc. etc.)
It's a complicated area.
Then PMIC operates independently from the kernel, and configuration even persists when powered off/during reboots.
HW is designed to be safe, but SW has to cooperate, including userspace. (some daemon that will help policing the whole device, based on many different inputs and by controling things that affect heat production - like preventing the user from setting backlight at max, limiting modem RF output to something that doesn't need huge amounts of power, etc. etc.)
It's a complicated area.
No, I would not trust Apple. That was my point, but seems you missed.
You really think Apple, Google , or any real company would go out of their way to disable safety limits that would cause batteries to explode?
After owning a couple android phones, real hardware manufacturers will do absolutely anything that improves profits.
That’s why I specified Google. I would also put Samsung in that category (despite their exploding battery episode).
He's simply pointing out that there needs to be some supporting work on the software side to minimize the risks. He's a pretty prolific hacker who's been around the Pinephone scene pretty much from the start and pointing out some things that were done as quick hacks to get things working in the early days that should be circled back on and fixed. I took his post more as a PSA than anything else.
Doesn’t iPhone have a warning when the phone over heats? And this phone has its cpu temperature monitoring disabled? I guess this is quite a specific example, but it seems you can trust Apple to not let your phone get so hot it melts, and you cannot trust pinephone.
The iphone usually doesn't come with beta (or even alpha) software. An approach like this would not make sense for what the Pinephone aims at.
This style of writing is responsible for 41% of the rage on the internet and I hate it. It's as if people forgot how to argue a valid point without becoming a troll. If this is the future of communication standards please someone just sneak up on me and insert an ice pick in my brain stem.
On the surface I think you're right - but the author appears to be a contributor in the PinePhone community or is at least involved enough to be patching the kernel and testing out various features of PinePhone. That makes me think the author is genuinely concerned about the safety risks, however I do think the alarming communication tone is probably a little over the top :)
What was wrong with it, assuming it's factually correct?
There evidentially is hardware logic in the battery itself so it's not factually correct. You might damange other pinephone components but the batter shouldn't catch fire.
I wouldn't trust something as overly-complex as Linux to prevent fires anyways.
I wouldn't trust something as overly-complex as Linux to prevent fires anyways.
Ok, so go to the Pinephone battery spec (everything is publicly available) and point me to where it says the in-battery protection circuit protects the under/overtemperature condition.
In fact it's just the common protection circuit that just cares about over/under voltage and over-current conditions (mostly just a short, because the cuttoff current limit is 6-8A and battery's max recommended sustained current is 1.4A). So you can overload the battery 3-4x for however long you want, and that circuit will do nothing.
https://megous.com/dl/tmp/d7402d89fca1a418.png
In fact it's just the common protection circuit that just cares about over/under voltage and over-current conditions (mostly just a short, because the cuttoff current limit is 6-8A and battery's max recommended sustained current is 1.4A). So you can overload the battery 3-4x for however long you want, and that circuit will do nothing.
https://megous.com/dl/tmp/d7402d89fca1a418.png
The thing that about me the most is how much it's pushing fear without any evidence of something bad actually happening. Has there been a single pinephone that has caught on fire?
I am not aware of any case of fire.
So unless it caused such a bad fire, that everybody involved died, I think I would know about it having followed the PinePhone very closely, especially since June for my blog.
That said, as the fix seems to be rather trivial, distributions should just check and ship a new kernel if necessary.
That said, as the fix seems to be rather trivial, distributions should just check and ship a new kernel if necessary.
I don't get this criticism. Doesn't it make sense to raise the alarm before the fire happens?
Yes, there were cases of Pinephone burning people's fingers, due to modem being used as a heatsink, and distros not doing any testing about thermal regulation working. You can easily get the modem to heat up to 70-80 deg C in that case. With regulation on, it would not get over 60, which while not pleasant is not at least hurtful.
Seconding this question. If it'd been me writing the article, and all the claims are true, it would've been a profanity-laced screed condemning the entire project as a pack of incompetent morons.
It wouldn't charge so we turned off thermal regulation
Jesus effing Christ.
It wouldn't charge so we turned off thermal regulation
Jesus effing Christ.
Move fast and break things !
I recall once a co worker said they'd never use Android again since it froze when trying to call 911.
Gives Apple more ammo in their fight against Epic, users expect their phones to work , which Apple can't guarantee if anyone can run whatever binary they find.
I recall once a co worker said they'd never use Android again since it froze when trying to call 911.
Gives Apple more ammo in their fight against Epic, users expect their phones to work , which Apple can't guarantee if anyone can run whatever binary they find.
[deleted]
The article is aimed at distro users to take action and start prodding the distro maintainers about how they make sure safety basics work on their phone. Style is tailored to that.
Why would you be running on battery while connected to the dock and an external monitor?! That seems like doing some math without thinking about the practical mechanics of being docked.