On Wed, Dec 03, 2008 at 05:49:35PM +0100, Frans Pop wrote:
My guess would be that the reason for the paranoia field is exactly that
they wanted to allow for the possibility of a struct getting extended
without them noticing!
I assumed the same thing.
I guess it would make sense to at least
Processing commands for [EMAIL PROTECTED]:
tags 504721 pending
Bug#504721: Console broken on debian-installer on Sparc LDOM
Tags were: patch
Tags added: pending
End of message, stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
On Tue, Dec 02, 2008 at 10:50:26PM +0100, Frans Pop wrote:
Someone who can actually write in C please check the code and let me know
if anything can be removed or is missing. I may well have added unneeded
includes for example and I have no idea what the original sprintf
statements were
Jérémy Bobbio [EMAIL PROTECTED] writes:
On Tue, Dec 02, 2008 at 10:50:26PM +0100, Frans Pop wrote:
As we are not interested in the settings of the serial line or by the
state of the VT, we can just omit the struct declarations and be fine
with a dummy buffer.
Don't you risk overflowing the
On Wednesday 03 December 2008, Ferenc Wagner wrote:
Don't you risk overflowing the buffer by not using a union of the two
structs? Or are both guarranteed to never grow above 256 bytes?
The original code looks to have included a paranoia field in struct u of
3 times the size of serial_struct,
Frans Pop [EMAIL PROTECTED] writes:
On Wednesday 03 December 2008, Ferenc Wagner wrote:
Don't you risk overflowing the buffer by not using a union of the two
structs? Or are both guarranteed to never grow above 256 bytes?
The original code looks to have included a paranoia field in struct
On Wednesday 03 December 2008, Ferenc Wagner wrote:
But why magic constants? Why not a simple union of the two structs?
The original paranoia isn't any better in this respect. Or do we
try to avoid the need to recompile if the struct is later extended?
That sounds silly... Maybe I'll learn
Processing commands for [EMAIL PROTECTED]:
tags 504721 patch
Bug#504721: Console broken on debian-installer on Sparc LDOM
There were no tags set.
Tags added: patch
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
tags 504721 patch
thanks
On Wednesday 26 November 2008, Jérémy Bobbio wrote:
So, the problem is that reopen-console gives preference to the value
in 'console handover' line, which is incorrect on sparc (refers to a
real terminal console even if one is connecting through serial). If
it is
On Tuesday 02 December 2008, Frans Pop wrote:
Someone who can actually write in C please check the code and let me
know if anything can be removed or is missing. I may well have added
unneeded includes for example and I have no idea what the original
sprintf statements were supposed to do.
On Sun, Nov 23, 2008 at 10:15:47PM +, Jurij Smakov wrote:
The logic in reopen-console is the following:
[… a very good analysis …]
So, the problem is that reopen-console gives preference to the value
in 'console handover' line, which is incorrect on sparc (refers to a
real terminal
Hi,
I looked into it, and here's what I get on my SunBlade 1000 when I
boot using serial console:
~ # dmesg | grep -i console
[0.00] console [earlyprom0] enabled
[ 53.918290] Console: colour dummy device 80x25
[ 53.971361] console handover: boot [earlyprom0] - real [tty0]
[
severity 504721 serious
thanks
On Sunday 23 November 2008, Jurij Smakov wrote:
So, the problem is that reopen-console gives preference to the value
in 'console handover' line, which is incorrect on sparc (refers to a
real terminal console even if one is connecting through serial).
As serial
Processing commands for [EMAIL PROTECTED]:
severity 504721 serious
Bug#504721: Console broken on debian-installer on Sparc LDOM
Severity set to `serious' from `important'
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
14 matches
Mail list logo
