[HN Gopher] Print this file, your printer will jam (2008)
___________________________________________________________________
Print this file, your printer will jam (2008)
Author : segfaultbuserr
Score : 324 points
Date : 2020-12-26 13:41 UTC (9 hours ago)
(HTM) web link (nedbatchelder.com)
(TXT) w3m dump (nedbatchelder.com)
| SoSoRoCoCo wrote:
| For the last 5~7 years, thousands of software-only programmers
| have been discovering Arduino and Raspberry Pi, and have been
| learning about the real-world consequences of interfacing to
| hardware. I help out at a local hackerspace and the excitement of
| someone discovering a software/hardware interface bug is
| contagious.
|
| Here's an example: someone was trying to make a plant watering
| machine and was using a FET to control the DC motor. The wire to
| the FET was about 15 feet long so the slope from the poor GPIO
| was horrendous, and the motor would basically brownout because it
| couldn't overcome the initial stall di/dt. The idea that not all
| edges are perfect 90 degrees was eye opening to him.
| robocat wrote:
| Is that because many software programmers use "genetic coding"
| techniques where bugs are randomly fixed until the software
| works? Or were you mostly dealing with newbie programmers?
|
| It's not like software doesn't have similar failure modes to
| hardware, right?
| SoSoRoCoCo wrote:
| I don't think it was... maybe? I've seen people hack circuits
| they way they hack code: keep trying small tweaks until it
| works. Then when they connect two circuits and it doesn't
| work, they go back to the fundamental RTFM. It could also be
| the skillset: circuits are more a creative art form, logic is
| more... logic. (But that doesn't always hold because I've
| encountered cache/CAM RTL designs that were beautiful.)
|
| Failure modes are different. A transistor can go bad if you
| accidentally drove it too hard, so now you might need to
| replace every part until the circuit works. And maybe one of
| the xtors in your box is bad. Or maybe a wire isn't making a
| good contact. Just the physical aspects alone without
| bringing an oscilloscope into the mix ("Why is my signal so
| noisy? Oh, it's the fluorescent lights, or the cheap USB hub
| noise in 400MHz spectrum, or the wall-wart...") can be
| maddening.
|
| Mostly I think the people I helped out seemed to forget that
| "digital" only exists inside the O/S, whereas the real world
| is analog, and real-world debuggers are more abstract than
| using, say, gdb or journalctl.
|
| But then I work with MY mentors, and they have an even larger
| set of debug skills based on extensive component knowledge
| that reminds me of chess grandmasters who know all the
| openings. E.g, being told I'm using the wrong OpAmp because
| that particular device's temperature sensitivity isn't
| suitable for frequency-range I'm designing.
| temac wrote:
| There are some reasons Electrical Engineering is a thing.
| When you open the datasheet for a chip, all the cool
| numbers in nice tables are not just there to be pretty, but
| because they are useful to design a circuit to put the chip
| in... And then you have your classic engineering subjects
| applied to electrical circuit constructs, like filtering,
| stability of feedback loops, etc.
|
| In the end you can design simple/medium-complexity digital
| electronics PCB with some common knowledge on PSUs, digital
| interfaces (including layout/return-current/impedance
| control) with the right tools, but non-trivial analog I
| would not even bother, I leave it to people with a real
| training in this field.
| myself248 wrote:
| Oh, dang, yeah. Hackerspace here too, and software people
| colliding face-first with electrical reality is an endless
| source of learning, amusement, and project delays. Some quality
| time with an oscilloscope goes a long way, but still cannot
| overcome all stubbornness.
| Evidlo wrote:
| Here's a semi-related question that maybe somebody can answer.
|
| Why is it that despite listening on TCP 9100, some printers will
| just print the source code when you send them a PDF or Postscript
| file with netcat?
|
| Is there some special PJL command to put it into Postscript mode?
| Are there any networked printers around nowadays that don't
| support Postscript?
| tonyedgecombe wrote:
| >Is there some special PJL command to put it into Postscript
| mode? @PJL ENTER LANGUAGE = POSTSCRIPT
|
| >Are there any networked printers around nowadays that don't
| support Postscript?
|
| Yes.
| jagged-chisel wrote:
| "...despite listening..."
|
| Yes, there's a protocol behind that port. Just like there's one
| behind port 22, 80, 443... you can't just dump http to 443 and
| get a useable document in return.
| tonyedgecombe wrote:
| Actually that is exactly how the printers listened on port
| 9100. You open a connection and dump the raw print file. This
| "protocol" was introduced by HP with their JetDirect print
| servers.
| buckminster wrote:
| A lot of printers, by default, function like an ancient
| teletype. They interpret incoming data as something like ASCII
| and print out the text. You need to send the correct escape
| sequence (i.e. a sequence of bytes starting with 0x1B) to
| switch into a more modern mode.
| jschwartzi wrote:
| A lot of Postscript printers are configured to print source
| code when there's a syntax error in the file. My 2017 HP laser
| printer has this as an optional feature.
| tonyedgecombe wrote:
| A lot of printers default to PCL first which allows plain
| text printing. Some will auto detect the language but to be
| safe you would use PJL (Printer Job Language) to specify the
| print file format.
| csours wrote:
| This brings me back to night shift production support: My
| infrastructure buddy came to my desk at about 1 AM and said,
| 'Hey, I emailed you a Word doc, could you print it for me?'. I
| opened it and hit print and my computer immediately went to blue
| screen. He said 'Yea, that happened to me too, I wondered if it
| was just my computer'.
|
| Nowadays, the suspicion meter is much more sensitive.
| StreamBright wrote:
| My printer jams with anything I want to print. I do not even
| understand how we got here. There are 21313 different software
| installed on my system because of this printer and it is pretty
| useless.
| dheera wrote:
| Considering PostScript is Turing complete, it is still possible,
| and will always be possible, to make a PostScript file that takes
| 3 seconds to interpret, despite advances in CPU technology.
|
| Have modern laser printers solved the problem mechanically?
| WalterBright wrote:
| That's nothing. With Star Trek computers, type in something
| illogical and either the computer will explode or the poor
| keyboardist will get electrocuted and thrown across the bridge.
|
| I attribute much of the trepidation from early computer users to
| typing in the wrong thing to having watched Star Trek.
| lmilcin wrote:
| I have seen a bug where the device came from clients completely
| wiped. Mind, that this device has been distributed to millions of
| people. We would see couple hundred of these came every day, with
| completely clean flash.
|
| The interesting part was that nowhere in the code was any
| sequence that could clear the flash.
|
| After very lengthy and expensive bug hunting we have determined
| the cause.
|
| The flash protocol had an unlock sequence that required a bunch
| of magic operations before the write could be performed.
| Somebody, at some point decided to use "unlock bypass" function
| to disable this magic sequence, ie. allow writes without magic
| bypass sequence. This was done to improve write performance when
| the software was upgraded in the field (with customers
| potentially impatiently waiting for it to complete).
|
| Unbeknownst, there was a coupling between a remote part of the
| circuit and the lines between MCU and the flash that caused noise
| to be introduced to the communication. The unlock sequence was
| the only thing that prevented noise to be interpreted as valid
| operation. The probability was still very low of this happening,
| but with millions of devices in the field it was enough to get
| about 100 failures a day.
| hawktheslayer wrote:
| This is why I love bugs, especially the sporadic ones--often you
| grow in understanding of the underlying system or code as you
| solve them.
| segfaultbuserr wrote:
| > _especially the sporadic ones_
|
| Yes, but there's only a fine line between "sporadic but
| solvable by analysis" and "too sporadic to be reproduced or
| solved..." Device driver problems are often from the second
| category... Nevertheless, it can get interesting if the problem
| is reproducible like the "500 miles email" or this printer.
| marcan_42 wrote:
| Nothing is too sporadic to be reproduced, you just haven't
| found how to reproduce it yet :)
|
| I once solved a once-in-a-petabyte bug at Google, when I was
| still working there. One of our systems ran in two data
| centers on the same data, and the cross-check was detecting a
| _record offset_ mismatch but not a data mismatch (?!);
| retrying the process almost always fixed it. Long story
| short, there was a buffer overread in Google 's bespoke zlib
| compressor that caused it to emit slightly less efficient
| compressed data (one or two bytes longer)
| nondeterministically, even though the data was perfectly
| well-formed. We were detecting compressed records being at
| different offsets, even though the uncompressed data matched.
|
| Another Google one involved doing a postmortem on a _single_
| instance of bad data ending up on a system. I traced that
| back purely from logs to having been caused by a kernel panic
| two systems upstream, that caused disk data to not be flushed
| while metadata was, so on reboot the system picked up garbage
| from the disk sectors in the file, which turned out to be
| well formed data from a different file and it trickled down
| the layers.
|
| Also, this one has made the rounds on HN a couple times
| (second time I fix a golang runtime heisenbug too; first one
| was also fun):
|
| https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/
|
| And I recently fixed an OBS bug that has been randomly
| crashing audio for streamers for at least 3 years. I found a
| reliable repro that involved scripting monitoring mode
| toggles dozens of times per second; along the way I found and
| fixed 3 other bugs. That one was exacerbated by some of the
| OBS developers having built a rhetoric that those failures
| were caused by user configuration mistakes, because they
| often went away after changes - when what was actually going
| on was that users were blindly trying things to solve the
| problem, and sometimes stumbling on a somewhat stable
| workaround. (That one hasn't been reviewed/merged, still in
| the pipes).
|
| Then there was that bug in The Homebrew Channel that I
| introduced after adding freetype/TTF support... That was a
| heap corruption that was crashing things way later (embedded
| baremetal code, so no memory protection or debugging tools
| beyond remote gdb). Finding that one ended up involving
| dumping memory around the corrupted heap and following
| pointers to what eventually turned out to be graphics queue
| entries, then following texture pointers and teaching myself
| how to read swizzled character textures from hexdumps... I
| eventually found I was not allocating entries for space
| characters in strings, but was incrementing the index on
| spaces anyway.
|
| Lots of fun bug hunting stories...
| lambda wrote:
| My dad had a similar story about a bug report. This was back in
| the day when terminals still used paper rather than CRTs; actual
| teletypes. The bug report was something like "if I print a page
| feed on such and such terminal model, it will catch fire."
|
| The bug report form (which was paper in those days) had a few of
| the usual checkboxes and fields to fill in, including one for "is
| the problem reproducible?" That box was checked. Someone had
| actually gone to the effort of standing by their terminal with a
| fire extinguisher, running the same command and putting out the
| fire when it caught fire again.
|
| It turns out the problem was in some software that emulated page
| feeds by doing repeated line feeds. Some overflow or underflow
| bug caused an integer to wrap around, so instead of advancing a
| few lines to the next page, it would try to advance thousands or
| millions of lines. This particular terminal model was a new, high
| speed one, so it would try to advance the paper really fast. It
| was using those perforated strips at the sides, with the pegs
| that went into the holes. The pegs and holes weren't perfectly
| aligned, so the pegs would sometimes clip the holes a bit,
| causing some bits of paper to shred and get kicked up as dust.
| Along with a spark, I don't recall if it was from the motor or
| just static buildup caused by the friction of the paper, and the
| paper dust would ignite, causing the terminal to catch fire.
|
| I just love the image of whoever submitted that bug report,
| seeing the "is it reproducible" checkbox on the form, and
| standing by the terminal with a fire extinguisher to put it out
| while doing the same thing to make sure the problem was
| reproducible.
| SilasX wrote:
| Yeah, that's dedication! Most bug report handlers today won't
| even try to reproduce the bug on a weaker machine. Forget fire
| risk!
| segfaultbuserr wrote:
| > _so instead of advancing a few lines to the next page, it
| would try to advance thousands or millions of lines. This
| particular terminal model was a new, high speed one, so it
| would try to advance the paper really fast. [...] causing some
| bits of paper to shred and get kicked up as dust. Along with a
| spark [...] causing the terminal to catch fire._
|
| Great story! It really gives a new interpretation to the
| classic phase "halt and catch fire." The original
| interpretation was the apocalyptic myth that the CPU starts
| switching the bus really fast, overheats the bus drivers, and
| eventually ignites the electronics, which doesn't make much
| sense. Now we have a more realistic one. To be precise, not
| "halt and catch fire", but "CRLF and catch fire"?
|
| BTW, legends also say that the flammability of early printers
| was the origin of Unix's "lp0 on fire!" joke error message,
| which can still be seen in Linux for USB printers.
| /* * Get and print printer errors. */
| static const char *usblp_messages[] = { "ok", "out
| of paper", "off-line", "on fire" };
| bayindirh wrote:
| The flammability of old printers came from a combination of
| paper dust, worn out printing ribbon and possible presence of
| a flammable cleaning solution IIRC.
|
| More details are here: https://marc.info/?l=linux-
| kernel&m=102893054014512&w=2
|
| So at the end of the day, it's more of a reality than a joke,
| sadly.
| m463 wrote:
| The IBM mainframe high-speed printers from decades ago made it
| possible to overprint the same line several times.
|
| My memory of this was fuzzy, but I believe when you sent lines
| to the printer, there was a control code in the first column to
| have normal printing or to overprint the last line:
| | v line-of-text +this-overprints-previous-
| line
|
| There were all kinds of things that you could do that were non-
| optimal, like overprinting lots and lots of stuff until it wore
| out the paper or making many things print simultaneously. If
| you did too much, the printer would stop and open the cover -
| think a 5x5x8 box opening its lid.
|
| To be clear - these were basically chain saws with hammers
| behind the chain all controlled by software.
| btilly wrote:
| Realistically the printer probably caught fire under normal
| operations, then they went through everything that happened
| leading up to it, one step at a time, to figure out what caused
| it to catch fire. That is what let them submit a bug report
| with "this causes it to catch fire" rather than, "Printer
| caught fire randomly."
|
| In the process of narrowing down which command did it, they
| demonstrated reproducibility.
| templarchamp wrote:
| If you keep jamming few times, it would heat up the printer which
| would change the absolute clock frequency and the printer would
| start working again - just a thought. As a software guy, "it
| works locally but when it is tested in production real world, it
| does not", lol
| dang wrote:
| If curious see also
|
| 2014 https://news.ycombinator.com/item?id=8176464
|
| Discussed (a bit) at the time:
| https://news.ycombinator.com/item?id=376067
| satysin wrote:
| I got my start at Xerox working in their photocopier "QA"
| department. I say "QA" because it was more a factory setup than
| quality assurance office. Anyway we had test cases in folders
| with instructions on the front to configure the copier. Just the
| usual things like two-page scan to offset or collated with
| staples and a cover sheet, etc.
|
| Every now and then a "strange" case would be sent down of a
| certain job type that would cause the copier to break and hit
| "UM" or "unscheduled maintenance" exactly like this story.
|
| Had some interesting things pop up such as very creative ways
| people managed to bypass the currency detection to prevent
| printing (totally crap) currency copies or causing the printer to
| fail correctly printing the Machine Identification Code, even one
| scan to email job that caused a crash in the SMTP client so it
| would endlessly loop sending the same scan to the same email
| address every 5 minutes (300 second timeout) until you rebooted
| the machine.
|
| Fun times! This was actually how I got started with software
| development. I was interested in the copiers ESS (Electronic Sub
| System) which was a very basic Intel system running LynxOS
| essentially bolted to the back of the copier. I was chatting to
| some of the OS devs about RTOS and how it differed from a
| "normal" OS so learnt C with books they gave me and answered many
| of my questions.
|
| From there I managed to get a job up in the "real" QA department
| testing the printer drivers for Windows 9x, NT4, 2000 and the
| "soon to be released" Windows XP (or Whistler as it was known
| during development). I learnt how to use the Windows Debugger and
| about printer driver development which almost made me want to
| leave humanity and live in a cave somewhere in South America (:
|
| Luckily I got to move into the "nicer" world of C++/MFC and then
| .NET (anyone remember Managed Extensions for C++ aka C++/CLI?!).
| Like I said, Fun Times!
| loloquwowndueo wrote:
| Lol "OpenOffice can't print on Tuesdays"
| https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...
| thewebcount wrote:
| I hit a similar issue in OpenGL on macOS about 10 years ago. We
| had a fairly complex set of draw calls. It worked fine on high-
| end machines, and was perfectly usable, if a bit slow, on mid-
| range machines, but on low-end iMacs with crappy Intel graphics
| cards, it would cause the machine to panic and reboot.
|
| It ended up being that the draw calls filled up the smaller
| command buffer on the low end card, and the driver would crash.
| In talking with the implementors, they explained the situation,
| so I asked, "How do I determine that I'm filling up the command
| buffer?" The answer was basically, "The size of the command
| buffer is an implementation detail and there's no way to query
| OpenGL for it or for the size of the commands you're adding."
| Gee, thanks!
|
| We ended just breaking up the draw calls into more smaller calls
| and it solved the problem, but this entire bug was such an
| ordeal. Thankfully we're moving away from OpenGL and things are a
| bit more sane in Metal. Had I not had access to the OpenGL team
| at Apple at the time, there's no way I would have been able to
| figure out what was going on. I'm not sure if I would have
| thought to do the same work in smaller batches.
| marcan_42 wrote:
| That's a driver bug.
| cmg wrote:
| I wonder if this was related to a kernel panic bug I ran into
| in Chrome around the same time! Long story short, we were using
| a library (Modernizr) on our web product that checked for some
| kind of OpenGL support that we didn't actually need, and just
| running that code would trigger a driver bug. Disabling that
| fixed it!
| quercusa wrote:
| From the comments, the 500-mile email:
| http://www.ibiblio.org/harris/500milemail.html
| jamestnz wrote:
| This reminds me of a fun story about another unusual failure mode
| involving some supposedly valid (but highly specific) input
| content: Where listening to a certain podcast in your Mazda will
| reliably crash the car's stereo system.
|
| "The Roman Mars Mazda Virus" https://gimletmedia.com/shows/reply-
| all/brh8jm
| 11thEarlOfMar wrote:
| Tell me if this is a bug...
|
| After driving a new car to work for 2 years, the traction control
| started kicking in on certain curves. I take a windy road to work
| and had never had traction control activate. When it kicked in,
| it pulsed the right front brake and slowed the car quickly,
| likely unnerving the guy tailgating me. This happened several
| times, both going to and from work. The road was perfectly dry,
| no snow or rain. Same turns at the same speed as always.
|
| The clues are was that my rear tires had worn and I replaced them
| a few days before. And, I drive a Tesla Model 3. It's a rear-
| wheel drive version and the front tires still had good tread so I
| didn't replace them.
|
| Why the right front tire?
|
| What I finally brained out, which you may have quickly realized,
| is that the diameters of the worn front and new rear tires were
| then slightly different. The front had a lower diameter than the
| rear and therefore turned at a slightly faster rate when driving.
|
| When I took a hard bank, the outside wheels also turned faster
| than the inside as they do in any turn. That increased the delta
| in spin rate the most between the outside worn front tire and the
| inside new rear tire. The traction control determined that the
| right front must be slipping and pulsed the brake on it.
|
| I replaced the front tires and everything went back to normal.
| londons_explore wrote:
| This is a bug...
|
| The system should learn the tyre diameters after driving a half
| mile or so on a new set.
| jhoechtl wrote:
| Are you a car safety expert or is this your assumption how a
| car should behave?
|
| I doubt it is a road safety requirement for a car to learn
| tire diameters.
| throwaway0a5e wrote:
| >I doubt it is a road safety requirement for a car to learn
| tire diameters.
|
| If you want to have hair trigger traction control systems
| then it kind of is.
| rightbyte wrote:
| You do tire rolling radius adaption. Otherwise you can't
| have fancy traction control.
|
| A leaking tire will also give smaller rolling radius and
| that is usually how leak warnings works.
| t0mas88 wrote:
| It's standard for most cars to detect the tire diameters.
| Not in the last place because most "sports car" brands also
| allow you to choose a different width rear tire. And that
| typically also has a slightly different diameter.
| BoorishBears wrote:
| They do learn tire diameters, they can even detect a flat
| using this information.
| centimeter wrote:
| That sounds unreasonable to me. The (virtual, on a Tesla?)
| differential should allow at least the amount of slip induced
| by a new tire.
| mrgordon wrote:
| Many cars like 4WD require all tires to be replaced at the same
| time to avoid weird issues like this with the automated systems
| riverdroid wrote:
| There might be some software issues at play with some modern
| AWD systems that I am not aware of, but it's traditionally a
| mechanical issue with 4WD and AWD. 4WD has a physical link,
| so having two different diameters linked stresses the links
| and tears the rubber. With AWD there is a differential, and
| different diameters cause mechanical stress and wear in a
| mechanical diff.
| jakear wrote:
| My understanding is that AWD has computer controlled power
| distribution and 4WD has a diff. My 4WD has a (lockable)
| center diff.
| centimeter wrote:
| Not quite: AWD has diffs between each of (FR,FL),
| (RR,RL), (F,R).
|
| 4WD has diffs between (FR,FL) and (RR,RL), but it has a
| _transfer case_ (like a permanently locked center diff)
| between F and R.
|
| So you're not supposed to use 4WD on dry asphalt roads
| because the natural slippage between front and rear has
| no easy way to release itself.
|
| Modern diffs are usually limited slip, which helps
| prevent spinning tires. LSD can either be mechanical or
| computer controlled. Computer controlled LSD can apply
| brakes to individual tires.
| autotech wrote:
| Not a bug. This is a weird but documented phenomenon. There are
| multiple published technical bulletins on similar issues caused
| by uneven tire wear/replacement. I must admit that I never came
| across traction control false activation due to 2 new tires. I
| have seen burnt transfer cases on AWD with this though. Were
| you advised by a shop to change just 2 or was it your
| independent decision?
| cowsandmilk wrote:
| Why not just move the tires from the front wheels to the back?
| jhayward wrote:
| In commercial tire shops in the US the tires with the most
| tread always go on the back regardless of any other
| consideration.
|
| This is because losing traction in front causes understeer,
| which is usually easily managed by typical drivers. On the
| other hand losing traction in back causes oversteer, which is
| often very rapid in attack and severe in extent. For some
| vehicles it is essentially impossible for a non-professional
| driver to maneuver out of an oversteer event.
|
| So for safety sake the best tread always goes on the back.
| Most shops will refuse to do anything else.
| treeman79 wrote:
| Then there is my eldest daughter.
|
| "Dad, car has been a little bumpy for the past month"
|
| I hop in go down to road. Experience is best described as
| driving on square tires. https://youtu.be/QF7odK55gkI
|
| Both front tires had massive bulges sticking out.
|
| She had been driving like that for a month.
| pengaru wrote:
| She's _your_ daughter...
| treeman79 wrote:
| Oh I have my own stories of being completely oblivious,
| or not wanting to bother others.
|
| However she was a special needs adoption due to age. Only
| had her ~4 years at that point.
| necovek wrote:
| Does this make as much sense for front wheel drive cars?
| Both of my FWD cars get front tires to wear more, and if I
| wanted to keep the better tread on the back, I'd never
| rotate them, and fronts would wear out much faster than the
| backs.
|
| Not to mention that front wheels also have bigger brake
| rotors, so worse tread up front would also mean worse
| breaking.
| throwaway0a5e wrote:
| This is one of those myths that just needs to die.
|
| "Put the good tires on the back" is a terribly inaccurate
| rule of thumb. Whether you want the good tires on the rear
| or the front is gonna depend on how the vehicle handles.
| Most modern mom-mobile type crossover are so biased toward
| under-steer (usually from a combination of rear weight and
| stiff front sway bar) that they need all the help they can
| get up front and putting the better two tires on the rear
| is just wasting traction because that end was never going
| to break traction anyway.
|
| Also, Firestone happily puts fronts only on my junk.
| autotech wrote:
| The problem is that vehicle handling is dependent on
| equal grip from all 4 tires. When you introduce
| differential in traction front to rear, you can throw the
| "understeer or oversteer bias" directly out the window.
| Modern cars do a great job compensating for less than
| ideal conditions but there is a limit. If you still think
| the new tire on the rear rule of thumb is inaccurate,
| watch this:
|
| https://youtu.be/gSz7cm6MwH0
| bbddg wrote:
| Yeah isn't this why you should rotate your tires regularly?
| jhoechtl wrote:
| You get downvoted but yes, that's the reason for swapping
| front to back and vice versa.
| crazyjncsu wrote:
| Just so the laymen here don't think this is some kind of
| hack, this is what is referred to as "rotating your tires",
| which should sound familiar.
|
| The problem is that tires are often not rotatable due to
| staggered setups where the front and back tires are different
| sizes (very common) or due to directionality of tires (less
| common).
| ComputerGuru wrote:
| Different sizes means you can swap left to right and right
| to left. Directionality means you can swap front to back
| and back to front. Directional tires of different sizes
| means you can't swap a damn thing (as drivers of Porsche
| and some BMW configurations find out quickly enough.)
| Cactus2018 wrote:
| Might have different tire size front and back -
| https://tiresize.com/tires/Tesla/Model-3/2020/
| simonebrunozzi wrote:
| It's a terrible bug, but at least Tesla should be able to fix
| it quickly.
|
| Just need to add a check that calculates the average of these
| values over the past few hours or days, and decides to modify
| the tipping points for traction control accordingly.
|
| Did you consider contacting Tesla and submitting a bug report?
| pfranz wrote:
| Isn't individual rotation speed how most cars detect
| underinflated tires? I imagine this problem would also happen
| if the tires had different tire pressures.
| yholio wrote:
| Sounds like a safety critical bug. Rotating tires and replacing
| them asymmetrically (for example, after a tire explosion for
| me) is regular practice. If a small difference in wear disables
| critical safety systems and engages them in inappropriate
| circumstances, this can lead to deaths.
|
| It seems simple enough to detect that, on a straight road with
| the steering wheel balanced, one of the wheels makes more
| rotations on average; then you calibrate the algorithm based on
| that. Sounds like a bug in this very algorithm, or maybe some
| hardware defect on your specific vehicle (i.e a sensor) that
| interferes with it.
| aidenn0 wrote:
| Many AWD cars require replacing tires in sets in the manual
| ComputerGuru wrote:
| As a long-time owner of AWD performance vehicles (Midwest
| for you, possible snow eight months of the year!) I can
| assure that whether or not you replace your tires four,
| two, or even just one at a time, there are absolutely zero
| visible/immediately tangible repercussions and the issue
| described with the Tesla is absolutely not normal even
| under those circumstances.
|
| As for the long term ramifications, you'll definitely see
| increased wear/camber on the opposing tire(a) and I've read
| it could theoretically cause issues with the diff, but I
| find that extremely hard to believe at least for the cats
| I've driven, because the front:back power ratio is
| dynamically recalculated and changed continuously depending
| on driving conditions. If it were 4WD rather than AWD, that
| might be the case though.
| bayindirh wrote:
| Opel Calibra is extremely sensitive to asymmetric tyre
| wear. The speed difference damages the third, central
| differential. To prevent the problem, you need to rotate
| your tyres periodically.
|
| It's one of the main reasons why that car is notorious in
| terms of maintenance.
|
| Too bad, I love that car though.
| o-__-o wrote:
| Okay here is anecdotal experience. I had a set of treads
| on my rear tire at 15/32 while the fronts where at 9/32.
| Viscous coupled AWD with traction control via four-wheel
| braking. I first noticed something was up when the car
| would launch rather quickly. I added an odb-2 reader and
| saw my AWD clutch was engaging a lot. Thought this was by
| design due to my heavy foot. Then the clunking started.
|
| The AWD would rather stay engaged which puts strain on
| the transmission to shift harder. Over time this showed
| up as increased transmission temperatures. My
| transmission is sensitive to heat but has a poor design
| which makes any heat a very big deal. At about the same
| time I was researching new wheels and determined I could
| fit 9" wide tires in the rear vs 8.5" in the front. A
| staggered wheel set would give me more rear wheel power
| bias, but the closest I could get in tire size was still
| almost .5% larger in diameter.
|
| In all my research it turns out you need tires of the
| same size within 3/16 wear of each other to avoid non-
| full time AWD transmissions from doing dumb things like
| my car does. You see, the AWD clutch simply engages a
| power transfer unit and then depends on ABS to control
| power sent by the differential to individual wheels. That
| system needs to recalibrate itself regularly and it does
| this when the clutch disengages. When it doesn't, all
| sorts of warnings are tripped (in my car I went down 6
| floors of a spiraling parking garage exit at 15-20mph and
| at the 2nd floor a "service stabili-trak" icon appeared
| on my dashboard)
|
| In cars with a well designed AWD system this will not
| happen.. but most cars are not designed to engage in AWD
| for prolonged periods of time and are really there as a
| beefed up version of traction control. For instance my
| Torsen Quattro AWD Audi had full time AWD and never had
| this problem nor would a Nissan GT-R. But for that fancy
| Lexus or Hyundai AWD, you may want to make sure you stick
| to the recommended tire rotation schedule
|
| To end my story, I was at the service center and they
| mentioned I should get my transmission checked out by the
| bigger repair bay because of the clunking. I suggested it
| may be the wear of the tires and they agreed to see if
| that solved the problem. New set of tires and the
| clunking, extra AWD engagement, and transmission temps
| went away.
| Dylan16807 wrote:
| > In all my research it turns out you need tires of the
| same size within 3/16 wear of each other to avoid non-
| full time AWD transmissions from doing dumb things like
| my car does.
|
| 9/32 + 3/16 = 15/32 so I guess not
| ComputerGuru wrote:
| Interesting story. And yes, I was specifically referring
| to full-time AWD with or without a rear bias, like that
| in the Audi Quattro (who I personally think does an
| excellent job).
|
| I actually don't consider a car that doesn't have full-
| time AWD to be AWD at all, isn't that considered 4WD?
| o-__-o wrote:
| I understand AWD to be exactly that, all wheels providing
| driving traction. We have advanced long from the Audi 200
| days to where part-time AWD is as simple as $700 in parts
| (for my car).
|
| 4WD (4x4) is full time (typically selectable but cannot
| be changed while in motion). 4WD has a greater gear ratio
| to really put power to the wheels that have grip, so
| while all 4WD cars can be considered AWD, AWD cannot be
| considered 4WD. I'm sure some jeep owner can give a
| better rundown on why 4WD is named the way it is..
| ComputerGuru wrote:
| I don't think 4WD/4x4 is a strict subset of AWD or the
| other way around. One is typically manually selected, the
| other is _typically_ always on at a certain ratio but (at
| least in modern variants) dynamically adjusted (or at
| least theoretically adjustable) either on a front /back
| or even on a per-wheel basis based on dynamic real-time
| feedback.
|
| TBH the line has blurred considerably in recent years and
| what once would have been 4x4 (manually engaged fixed-
| ratio four wheel mode) is being marketed as AWD. I'm
| sitting in a rental GMC Terrain (very crappy car, with or
| without AWD) and it must be manually switched from 2WD to
| 4WD mode but it's an electronic button (rather than gear
| selection lever) that can be changed at speed, and can
| also be used in 4WD mode at highway speeds without
| redlining. This is considerably different from body-on-
| frame SUVs/pickups with "true" 4x4 mode that have regular
| 2WD but can be changed into 4L or 4H to get different
| gearing ratios inside the transfer case for four wheel
| drive.
| macintux wrote:
| > typically selectable but cannot be changed while in
| motion
|
| Not true for a long time now. Manually locking hubs
| required egress while stopped but at some point 4wd tech
| progressed.
| alistairSH wrote:
| In the US, 4WD (4x4) means when the system is engaged,
| the center diff is locked. Sometimes there'll be some
| combo of front and rear lockers or LSD units, but not
| always. When engaged, the center diff is locked, so these
| systems are typically only engaged off-road or in snow.
|
| And AWD is any system that drives all 4 wheels
| permanently. In fancy systems, the ratio sent to front vs
| rear might vary from 50/50 to 0/100, but it's always
| engaged to some extent. These systems are safe for
| regular on-road use.
|
| Pick-up trucks and truck-based SUVs usually have 4x4
| systems (with a few exceptions like the Land Cruiser and
| Lexus GX which are both AWD).
|
| Cute utes and cross-overs, plus the odd-ball sedans and
| wagons (Subaru, VW 4Motion, Audi) are usually AWD.
|
| Edit - as noted in a sibling comment, the line has
| definitely blurred with fancy electronically controlled
| and viscous couplings, but generally "truck" = 4x4 and
| cross-over/wagon = AWD.
| aidenn0 wrote:
| I don't know if it does or does not actually cause
| issues, but the manual for my friends Subaru definitely
| says the tire wear needs to be even (possibly in pairs?).
| It came up when she got a nail through one tire about
| halfway through the lifetime.
| Spooky23 wrote:
| None. Arguing with Tesla people on the internet is like
| arguing with vegans... not a productive exercise for either
| party.
|
| I have a guy at work who has been without a car for 4
| months due to Tesla fuckups, and he basically defends
| Elon's honor on the internet as a hobby.
| donkeyd wrote:
| It's almost like arguing with any other fanboy on the
| internet. Maybe the brand doesn't really make a
| difference, maybe it's just the being of a fanboy.
| throwaway0a5e wrote:
| Some fanboys are more numerous than others.
|
| Personally I find discussing Toyota on the internet to be
| far less productive than Tesla.
| falcolas wrote:
| The op isn't in an awd vehicle. He's in a Tesla with only
| RWD.
| Denzel wrote:
| This is not a bug.
|
| I also drive a Model 3, spiritedly. Of course, I've rotated
| my tires many times, on schedule, but I _replace_ them all at
| the same time. It's standard practice. I've never experienced
| OPs behavior.
|
| The algorithm is such that there's a limit to the amount of
| "slippage" it will accept before traction control engages. A
| difference in tire diameters, exacerbated by a hard curve,
| leads to more slippage than the algorithm is willing to
| accept. What do you think would happen if traction control
| was off? :)
|
| Furthermore, there are unknowns here - OP hasn't specified
| the diameter (between 2 and 8/32's) of their old tires. They
| simply stated that the tires had enough tread to meet their
| personal standards. Clearly traction control sees the
| situation differently.
| moonbug wrote:
| uhoh. you're going to rattle the Tesla fanbois.
| t0mas88 wrote:
| It may be "within spec" for a Tesla, but other brands with
| traction control don't have this problem. And that is a
| typical issue with Tesla, they have too many software guys
| and too little real world automotive experience. So they'll
| create these kinds of problems by implementing their own
| things instead of going with proven existing tech.
|
| The most rampant example was the rain sensor on the early
| model S. They decided not to buy the same perfectly working
| sensor that any German car had for 10+ years at the time,
| no they decided to implement the rain sensor by training
| some image recognition on the camera that's behind the
| windscreen. Worst idea ever, because it meant the 100k+
| euro Model S had no automatic wipers for a long time and
| when they got there it was worse at detecting rain than the
| standard sensor on a 20k euro VW Golf...
| jonahrd wrote:
| To specify further: this is a problem in Teslas with
| autopilot 2.0+ hardware, where they switched from 1 front
| facing camera to 3. That left no room for the Bosch
| rain/light/humidity sensor, so they put developed their
| own light/humidity sensor, but still didn't have enough
| room for rain sensing hardware. The solution was left up
| to the autopilot team since it was assumed (wrongly) that
| sensing rain using a camera was easier than using
| specific optical sensors designed for the task.
|
| Source: I worked on the replacement TH sensor.
| 11thEarlOfMar wrote:
| Mine thinks that a chip in the windshield is a raindrop.
| I had to turn off automatic wipers.
| Dylan16807 wrote:
| This is a bug.
|
| The slippage calculation should take tire size into
| account. Anything else gives you wrong numbers.
| jacquesm wrote:
| Definitely a bug. If tires are within spec the traction
| control should not trigger, it should trigger when a wheel
| slips, not when it is in fact having good traction.
| AndrewBissell wrote:
| A bug? In a Tesla? Naaaaaaah ...
| speedgoose wrote:
| It's fine, they will update your car remotely and remove
| the bug. Eventually. By the end of a year.
|
| Still want one though.
| foolmeonce wrote:
| Why would AI or fuzzy logic need to be provided with
| perfect sensors when human drivers are not? If you break
| 101 times out of 100, whoever rear ends you is at fault,
| 99 out of 100, OTOH..
| jacquesm wrote:
| Because traction control is a safety system and if it
| kicks in when you don't expect it it can turn a safe
| system into an unsafe one.
| foolmeonce wrote:
| Yes and a good driver can get you killed from good
| reaction time. Driving is a game of russian roulette that
| involves a lot of intelligences with poor senses doing
| random things.
| BoorishBears wrote:
| This is table stakes for TC which companies like Bosch
| solved and commoditized. I don't know why you're
| defending it.
| zeusk wrote:
| I guess people already forgot what caused 737 MAX
| m463 wrote:
| I believe tesla will recalibrate all this after you drive
| for a certain distance.
|
| Thing is - they would get complaints because the system
| would disable certain functions with a message during
| recalibration.
|
| I wonder if they have now turned the dial too far the other
| way.
| Dylan16807 wrote:
| If they can't recalibrate in the background, that's an
| entirely different problem. It's not a matter of turning
| a dial, it's fixing a flaw.
| ovi256 wrote:
| Any change of state in a system with inertia should have
| hysteresis! In this case, a minimum duration before restarting
| would have done the trick.
| segfaultbuserr wrote:
| > _Any change of state in a system with inertia should have
| hysteresis!_
|
| Or noise.
| famousactress wrote:
| I may have told this story before (perhaps back in 2008 if this
| was posted then) -- but my first gig in tech was QA for Hewlett
| Packard testing printer/scanner/copier units. At some point I
| scanned a photo of my then-girlfriend and crashed the unit. Was
| able to do it repeatedly, provided I scanned the image in
| straight/cleanly. I didn't come across any other images that
| reproduced the issue, only this one photo. The underlying bug was
| a buffer overrun of some sort, was fixed before shipping -- and
| the image became a part of the durable regression test suite for
| that department.
| m463 wrote:
| I can't help but wonder if Alexander Hamilton or Benjamin
| Franklin would cause printer problems too (for a different
| reason)
| abraae wrote:
| Sad that this rings a GDPR bell in my mind.
| romwell wrote:
| You don't need GDPR for this to have legal issues.
|
| As an amateur photographer, I'm pretty sure that you'd
| formally need a model release form for a commercial use of it
| to be legitimate[1].
|
| Of course, as with any legal issue, the company would weigh
| the probability of it being enforced vs. the hassle of doing
| it right... and it's pretty clear where the balance is in
| most cases.
|
| [1] https://www.dmlp.org/legal-guide/using-name-or-likeness-
| anot...
| Dylan16807 wrote:
| That's a publishing consideration, not really an image in a
| box in the engineering lab consideration.
| mhh__ wrote:
| Is it enough to buy her bottle of wine or something in
| exchange for being able to keep the photo indefinitely?
| m463 wrote:
| What if her name was Lena?
| ComputerGuru wrote:
| Not surprised there was a bug, but I am surprised it was
| patched (before or after shipping). I have an "enterprise
| grade" HP scanner (3500 F1) with buggy Twain drivers I had to
| manually disassemble and patch that will crash any time you try
| to duplex scan a single-sided sheet of paper. The blank page
| detection algorithm caused a null pointer dereference if two-
| sided mode was selected but the second side was elided.
|
| The bug reproduced 100% of the time with all available versions
| of their drivers in any application using the TWAIN rather than
| WIA or proprietary scanner interface. It was as simple as
| scanning any one-sided document in duplex mode. I escalated the
| issue to their engineers who kept insisting the issue was with
| my PC until the product was EOL'd just a year or two after
| production.
|
| I had other hardware issues pop up and ended up getting a
| Fujitsu for ADF document scanning and keeping the HP for
| scanning photos with the flatbed. Not many stand-alone hi-res
| dual color ADF/flatbed scanners out there.
| ryandrake wrote:
| If you're in software, you probably know this, but your bug
| was likely ignored not because it couldn't be reproduced, but
| because the engineers on the project were prioritizing
| feature work for the next version of the scanner, and did not
| have any support from management for fixing bugs in an
| already-shipping product. Sadly, driver software quality
| tends to max out at the level where customers won't return
| the hardware for a refund, and then the company abandons it
| and works on the next shiny new device.
| romwell wrote:
| Well, that's why the parent commenter was surprised that
| the scanning bug in the grandparent comment was fixed at
| all.
| Dylan16807 wrote:
| > If you're in software, you probably know this, but your
| bug was likely ignored not because it couldn't be
| reproduced, but because the engineers on the project were
| prioritizing feature work for the next version of the
| scanner, and did not have any support from management for
| fixing bugs in an already-shipping product.
|
| Well, yes, but is it normal to _insist_ no bug exists?
| baud147258 wrote:
| perhaps if HP support admitted there's a bug, depending
| on the support contract (if applicable), HP would have
| had to fix it
| mikewarot wrote:
| Back in the days of Windows 98, the HP LaserJet caused no end of
| headaches for me. The problem that was introduced by the compiler
| they used to build the print driver. To compute the paper size,
| margins, etc., floating point operations were used... but by then
| the driver had allowed the libraries that emulated the floating
| point processor to be unloaded, to save memory. (Due to the
| optimizing compiler)
|
| Any operation that involved computing the page size would crash,
| only if the floating point library had idled out of memory.
|
| I ended up forcing the library to be loaded at boot on all
| machines, and then things were stable.
| garaetjjte wrote:
| Related issue:
|
| >There have been various instances in the past (printer drivers
| from a manufacturer who shall not be named) that would enable
| floating-point exceptions and leave them enabled, meaning that
| some perfectly legitimate software would start crashing after
| calling into third-party code (such as after printing).
|
| https://randomascii.wordpress.com/2012/04/21/exceptional-flo...
| sharken wrote:
| No wonder that one of the DevOps success stories revolves
| around HP printer drivers and firmware:
|
| https://itrevolution.com/the-amazing-devops-transformation-o...
| cesarb wrote:
| One thing which I always considered a misdesign in Windows, is
| its tendency to run third-party code in-process. This includes
| COM objects, printer drivers, and many more.
|
| We had a problem similar to yours at a previous company. The
| software was written in a proprietary language which had its
| own runtime, and that runtime expected a particular value for
| the floating point control word. There are some third-party
| DLLs, including some printer drivers and Explorer extensions,
| which when loaded overwrite the floating point control word
| with their own notion of what should be the correct value (this
| behavior, as far as I could determine, is introduced by the
| compiler used to build these third-party DLLs). The unexpected
| value for the floating point control word would then lead to
| crashes, but these crashes would not happen immediately, and
| they would only happen if the user had done something which led
| to one of these third-party DLLs being loaded, like
| opening/saving a file (the open/save dialog in Windows loads
| Explorer extensions) or printing (which loads the printer
| driver).
|
| The solution was to, after every point in the code which opens
| a file chooser or prints anything, call into a small stub DLL
| we wrote, which had code to reset the floating point control
| word to what the runtime expected.
| moonbug wrote:
| Yeah, I've had a variant of that, wherein the printer driver
| turned on fpes.
| andi999 wrote:
| What is the floating point control word?
| adrian_b wrote:
| The floating point control word is a register in the Intel
| 8087 FP coprocessor and in all later Intel/AMD/etc.
| processors that implement the 8087 instruction set.
|
| That register contains bits that control various aspects of
| how the floating-point instructions must behave, e.g.
| rounding mode, precision and exception masks (also infinity
| type in coprocessors older than 80387).
|
| For the later SSE/AVX instruction sets there is another
| register with similar control bits for the SSE/AVX
| instructions.
| tonyedgecombe wrote:
| It's worse than that, at one point printer drivers were run
| in the kernel. I remember a customer site where just opening
| a queue blue screened the server.
| germanka wrote:
| Definitely a bug.
| Pxtl wrote:
| It's reassuring to know that printers have always been crap.
| libria wrote:
| Can we appreciate, though, the mechanical difficulty of a
| machine dealing with a stack of microns-thin sheets and
| precisely plucking 1 of them at a time off of it fairly
| consistently despite variances in environment humidity and
| paper thickness? Probably static electricity plays havoc in
| some cases here.
|
| I've worked with million dollar printing equipment in a factory
| before and it needed daily coddling as well.
|
| On the other hand, the printer software/protocol/driver
| developers have no excuses at this point. There's no reason for
| that to still be as bad as it is in 2020.
| dylan604 wrote:
| My 2 least favorite things about computers: Printing and Fonts.
| jnwatson wrote:
| Importantly, it was the two things that early Macs got right.
| Other than price, a 1990 Mac/LaserWriter combo is superior
| than a modern equivalent.
| thih9 wrote:
| Current status of apple printer setup seems right to me
| too. I'm happy that I can print wirelessly from macOS or
| iOS, without installing any drivers or configuring anything
| (other than the wifi password).
| jamiek88 wrote:
| Yeah Apple typically get printing and audio right. Hi res
| too.
|
| Lots of things they aren't so strong on but they have
| always been good at the above.
| bananamerica wrote:
| https://www.wired.com/story/why-do-printers-still-suck/
| coryrc wrote:
| Printers being crap led to the Free Software movement and the
| GPL
| avisser wrote:
| My favorite bug like this was me in my buddy's 2000 VW Jetta. The
| car had some electrical issues, but my buddy once remarked that
| the windows stopped working whenever he gave me a ride.
|
| I'm 6'4" and always slide the seat back whenever I get in a car.
| Turns out the circuitboard controlling the windows was under the
| passenger seat and had come loose. Moving the seat back caused a
| short, "breaking" the power windows.
|
| Turns out, the windows _did_ stop working when he gave me a ride.
|
| edit: "I have him" => "he gave me"
| jacquesm wrote:
| I had a Citroen ID 19B which had a pretty neat quirk: the
| starter relay would only get power if you switched on the
| headlights. I don't know if that was on purpose or not (some
| primitive anti-theft device) but I left it in because it was
| actually a neat feature.
| ComputerGuru wrote:
| It's a legal requirement to have headlights on any time the
| car is in operation (day or night) in some territories and
| manufacturers had different ways of enforcing it. Some
| unconditionally turned on the headlights for models sold in
| those countries, others had special variants earmarked for
| export to those countries. It seems Citroen found a clever
| way that didn't require too much fiddling to meet the legal
| requirement.
| jacquesm wrote:
| Not in 1968, the year that car was manufactured in, and
| none of the other ID's that I've seen had this particular
| quirk, it was either done by one of the (many) previous
| owners or a fluke. The wiring in those cars got very
| brittle over time and shorts were pretty common. That car
| came from France to NL (I imported it).
|
| Anyway, it was a fun gimmick and it helped to dissuade
| people from taking it for a ride. I never did find out if
| it was on purpose or accidental, that dash was not one to
| disassemble if you didn't need to.
| ComputerGuru wrote:
| Ah that would indeed be way too early for what I'm
| talking about; the earliest laws for mandatory operation
| or non-switchable daytime headlamps on a nationwide, full
| time basis I can find after a cursory search is Canada
| starting in 1989. Before that many countries had
| requirements that applied in certain areas or at certain
| times of the year (e.g. Finland on rural roads starting
| 1972) which would not account for such a design.
| sokoloff wrote:
| If you find yourself in such a car and needing to drive
| or have the car running with the headlights out, you
| might try setting just the first click of the
| emergency/parking brake and see if that turns the
| headlamps off.
___________________________________________________________________
(page generated 2020-12-26 23:00 UTC)