Return to Answer

The bug in how ListLogLinearPlot calculates explicit value for PlotRange -> All was finally fixed in version 10.0.0 (July 2014). But the underlying principle is still the same: instead of just passing PlotRange -> All for the FrontEnd it calculates explicit value of the plot range in the Kernel. The calculated value differs from the one selected by the FrontEnd which can be obtained using the plotRange function:

Using plotRange function from this answer one can determine absolute value for PlotRange -> All (without PlotRangePadding):

One can see that it is substantiantly wider than the value generated by ListLogLinearPlot. So it is clearly a bug in how ListLogLinearPlot handles PlotRange -> All. It basically has the same nature as the bug in handling AspectRatio -> Automatic by TreePlot: in the both cases the developer tries to calculate in the Kernel absolute value for a Dynamic option which by definition can be handled only by FrontEnd and get predictable failure on this way.

The bug in how ListLogLinearPlot calculates explicit value for PlotRange -> All was finally fixed in version 10.0.0 (July 2014). But the underlying principle is still the same: instead of just passing PlotRange -> All for the FrontEnd it calculates explicit value of the plot range in the Kernel. The calculated value differs from the one selected by the FrontEnd which can be obtained using the plotRange function:

Using plotRange function from this answer one can determine absolute value for PlotRange -> All (without PlotRangePadding):

One can see that it is substantiantly wider than the value generated by ListLogLinearPlot. So it is clearly a bug in how ListLogLinearPlot handles PlotRange -> All. It basically has the same nature as the bug in handling AspectRatio -> Automatic by TreePlot: in the both cases the developer tries to calculate in the Kernel absolute value for a Dynamic option which by definition can be handled only by FrontEnd and get predictable failure on this way.

The bug in how ListLogLinearPlot calculates explicit value for PlotRange -> All was finally fixed in version 10.0.0 (June 2014). But the underlying principle is still the same: instead of just passing PlotRange -> All for the FrontEnd it calculates explicit value of the plot range in the Kernel. The calculated value differs from the one selected by the FrontEnd which can be obtained using the plotRange function:

The bug in how ListLogLinearPlot calculates explicit value for PlotRange -> All was finally fixed in version 10.0.0 (July 2014). But the underlying principle is still the same: instead of just passing PlotRange -> All for the FrontEnd it calculates explicit value of the plot range in the Kernel. The calculated value differs from the one selected by the FrontEnd which can be obtained using the plotRange function:

Update for version 10.0.0

The bug in how ListLogLinearPlot calculates explicit value for PlotRange -> All was finally fixed in version 10.0.0 (June 2014). But the underlying principle is still the same: instead of just passing PlotRange -> All for the FrontEnd it calculates explicit value of the plot range in the Kernel. The calculated value differs from the one selected by the FrontEnd which can be obtained using the plotRange function:

x = Range[0.001, 1000]; y = 5 - Log[x]; pl = ListLogLinearPlot[Transpose[{x, y}], PlotRange -> All]; PlotRange /. Options[pl, PlotRange] plotRange[Show[pl, PlotRange -> All]] 

{{-7.19556, 6.90676}, {-1.90676, 11.9078}} {{-7.41591, 6.90676}, {-1.90676, 11.9078}} 

Original answer