Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Thu, 2011-12-22 at 11:32 +1100, Sridhar Dhanapalan wrote: > > That's exactly the feedback I was looking for, thanks. That's a UI bug > > in Sugar. I would strongly prefer the Sugar environment to behave more > > like Android, where any app/activity that is in the bg may get an > > instruction from the shell / OS to cleanup and exit. > > Good that we're on the same wavelength - I had a similar thought! > > The annoying thing about Android, however, is that for an app to > continue to work in the background it needs to be coded in that way. I > suppose that if we were to treat Sugar as an 'appliance' UI (which is > how I tend to think about it), this isn't such a bad idea. An additional problem is startup time. Python code tends to be a lot slower to load and initialize than compiled Java bytecode. Anyway, closing an activity automatically when memory is short would still be preferable to the current behavior of trashing the VM until the OOM kicks in. > A quick hack would be to limit the number of activities that can run > simultaneously. I agree. How about 4? Seems sufficient for most productive workloads. > Our next OS will likely have the Dextrose resource monitor [1]. I > don't think we should be expecting children to be managing their > system resources, though. It should 'just work'. That was an attempt to make users more aware of the physical limits of the system rather than make the system itself smarter. An unexpected consequence reported from Uruguay is that some children would open plenty of activities *intentionally* because "it's fun to see the laptop cry!" Well, I guess it means that the concepts of memory and CPU weren't too hard to grasp after all. Better not give them any pets, though. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Wed, Dec 21, 2011 at 8:51 PM, Bernie Innocenti wrote: > Anyway, closing an activity automatically when memory is short would > still be preferable to the current behavior of trashing the VM until the > OOM kicks in. That's exactly the point :-) >> A quick hack would be to limit the number of activities that can run >> simultaneously. > > I agree. How about 4? Seems sufficient for most productive workloads. I think we should look at the output of vmstat or read the smaps and take a decision based on that. Different units have different memory; some programs are memory hogs, or can become so if you open large documents. m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Thu, 2011-12-22 at 08:10 +0530, Anish Mangal wrote: > Its interesting. Uy dropped it. Py loves it. One change that does need > to happen is replace the 'Cry [ :'( ]' icon with a 'Tired' one [ :'S ] > . I won't say anymore than this here, there have been LONG *excited* > discussions on the merit and design of this :-) Changes that affect the user experience are controversial by their nature. Ideally, one would like to decide based on objective data, but usability studies have a tendency to be costly and inconclusive. -- _ // Bernie Innocenti \X/ http://codewiz.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On 22 Dec 2011, at 00:23, Martin Langhoff wrote: > On Mon, Dec 19, 2011 at 10:34 PM, Sridhar Dhanapalan > wrote: >> It's a recognition that no software is bug-free, and that users >> (especially children) will always find a way to make a system >> difficult to use. For example, children often load activities without >> closing previous ones. We can educate them to not do this, but it >> still happens on occasion. > > That's exactly the feedback I was looking for, thanks. That's a UI bug > in Sugar. I would strongly prefer the Sugar environment to behave more > like Android, where any app/activity that is in the bg may get an > instruction from the shell / OS to cleanup and exit. +1! (fwiw same as iOS), though the horse has already bolted due to the past calls to support GNOME ported applications with few design considerations for our resource targets. Perhaps we can release/exit activities that at least support the write_file() method, and maybe add an additional new method for something like remember_state(), seeing as the original design requirements were not strict enough in requiring developers to expect to completely resume state accurately (cursor position, UI view modes, etc). --Gary > Do you have any other end-user use cases that have Ctrl-Alt-Erase as a > solution? > > cheers, > > > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- Software Architect - OLPC > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Thu, Dec 22, 2011 at 07:21, Bernie Innocenti wrote: > On Thu, 2011-12-22 at 11:32 +1100, Sridhar Dhanapalan wrote: >> > That's exactly the feedback I was looking for, thanks. That's a UI bug >> > in Sugar. I would strongly prefer the Sugar environment to behave more >> > like Android, where any app/activity that is in the bg may get an >> > instruction from the shell / OS to cleanup and exit. >> >> Good that we're on the same wavelength - I had a similar thought! >> >> The annoying thing about Android, however, is that for an app to >> continue to work in the background it needs to be coded in that way. I >> suppose that if we were to treat Sugar as an 'appliance' UI (which is >> how I tend to think about it), this isn't such a bad idea. > > An additional problem is startup time. Python code tends to be a lot > slower to load and initialize than compiled Java bytecode. > > Anyway, closing an activity automatically when memory is short would > still be preferable to the current behavior of trashing the VM until the > OOM kicks in. > > >> A quick hack would be to limit the number of activities that can run >> simultaneously. > > I agree. How about 4? Seems sufficient for most productive workloads. > It would exactly be that. A hack. How do we suppose to tell the children you can't run more than 4 activities at once? >> Our next OS will likely have the Dextrose resource monitor [1]. I >> don't think we should be expecting children to be managing their >> system resources, though. It should 'just work'. > > That was an attempt to make users more aware of the physical limits of > the system rather than make the system itself smarter. > +1 > An unexpected consequence reported from Uruguay is that some children > would open plenty of activities *intentionally* because "it's fun to see > the laptop cry!" Well, I guess it means that the concepts of memory and > CPU weren't too hard to grasp after all. Better not give them any pets, > though. > Its interesting. Uy dropped it. Py loves it. One change that does need to happen is replace the 'Cry [ :'( ]' icon with a 'Tired' one [ :'S ] . I won't say anymore than this here, there have been LONG *excited* discussions on the merit and design of this :-) > -- > Bernie Innocenti > Sugar Labs Infrastructure Team > http://wiki.sugarlabs.org/go/Infrastructure_Team > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On 22 December 2011 11:32, Sridhar Dhanapalan wrote: > On 22 December 2011 11:23, Martin Langhoff wrote: >> Do you have any other end-user use cases that have Ctrl-Alt-Erase as a >> solution? > > I'll check with our education team and get back to you. This is a very > valuable discussion to have! Some scenarios from our Education Manager: - When an activity freezes - When an activity stalls during loading - When an activity does something strange - e.g. sound doesn't work, journal entry doesn't load properly - During collaboration (this is a big one!). e.g. one person sees interactions but the other isn't able to - just never completely loads, or connection is never properly established, or it's just behaving unpredictably I think the goal should be to make Sugar more robust so that these scenarios don't happen. Sridhar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On 22 December 2011 11:23, Martin Langhoff wrote: > On Mon, Dec 19, 2011 at 10:34 PM, Sridhar Dhanapalan > wrote: >> It's a recognition that no software is bug-free, and that users >> (especially children) will always find a way to make a system >> difficult to use. For example, children often load activities without >> closing previous ones. We can educate them to not do this, but it >> still happens on occasion. > > That's exactly the feedback I was looking for, thanks. That's a UI bug > in Sugar. I would strongly prefer the Sugar environment to behave more > like Android, where any app/activity that is in the bg may get an > instruction from the shell / OS to cleanup and exit. Good that we're on the same wavelength - I had a similar thought! The annoying thing about Android, however, is that for an app to continue to work in the background it needs to be coded in that way. I suppose that if we were to treat Sugar as an 'appliance' UI (which is how I tend to think about it), this isn't such a bad idea. A quick hack would be to limit the number of activities that can run simultaneously. Our next OS will likely have the Dextrose resource monitor [1]. I don't think we should be expecting children to be managing their system resources, though. It should 'just work'. > Do you have any other end-user use cases that have Ctrl-Alt-Erase as a > solution? I'll check with our education team and get back to you. This is a very valuable discussion to have! Sridhar [1] http://wiki.sugarlabs.org/go/File:Dextrose_resource_monitoring.png ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Mon, Dec 19, 2011 at 10:34 PM, Sridhar Dhanapalan wrote: > It's a recognition that no software is bug-free, and that users > (especially children) will always find a way to make a system > difficult to use. For example, children often load activities without > closing previous ones. We can educate them to not do this, but it > still happens on occasion. That's exactly the feedback I was looking for, thanks. That's a UI bug in Sugar. I would strongly prefer the Sugar environment to behave more like Android, where any app/activity that is in the bg may get an instruction from the shell / OS to cleanup and exit. Do you have any other end-user use cases that have Ctrl-Alt-Erase as a solution? cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On 20 December 2011 05:34, Martin Langhoff wrote:
> On Mon, Dec 19, 2011 at 12:05 PM, Martin Langhoff wrote:
>>> Ctrl+Alt+Erase doesn't work on XO-1.5s.
>>
>> You are going to build your own OS image, right? We can give you a
>> quick recipe to re-enable it.
>
> Here you go. Can be used to monumentally shoot yourself in the foot,
> so pull trigger with care:
> http://wiki.laptop.org/go/OS_Builder/Edit_a_config_file
>
> { I know one day Reuben will want to kill me for having published this
> recipe in the wiki. And he'll be justified. At least we live in
> different cities. }
Cool - thanks.
>>> This feature is used by teachers in the field, and by us in testing.
>>> Its removal is a regression for us.
>>
>> Can you explain the use by teachers in the field? Use during testing
>> and debugging is fine, but we all work for our end users :-)
>
> I am still very interested in your teacher use case here...
It's a recognition that no software is bug-free, and that users
(especially children) will always find a way to make a system
difficult to use. For example, children often load activities without
closing previous ones. We can educate them to not do this, but it
still happens on occasion.
The 'solution' is to quickly restart Sugar with a Ctrl+Alt+Erase. It
solves most problems, and it's faster than rebooting.
Sridhar
Sridhar Dhanapalan
Engineering Manager
One Laptop per Child Australia
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Mon, Dec 19, 2011 at 12:05 PM, Martin Langhoff wrote:
>> Ctrl+Alt+Erase doesn't work on XO-1.5s.
>
> You are going to build your own OS image, right? We can give you a
> quick recipe to re-enable it.
Here you go. Can be used to monumentally shoot yourself in the foot,
so pull trigger with care:
http://wiki.laptop.org/go/OS_Builder/Edit_a_config_file
{ I know one day Reuben will want to kill me for having published this
recipe in the wiki. And he'll be justified. At least we live in
different cities. }
>> This feature is used by teachers in the field, and by us in testing.
>> Its removal is a regression for us.
>
> Can you explain the use by teachers in the field? Use during testing
> and debugging is fine, but we all work for our end users :-)
I am still very interested in your teacher use case here...
m
--
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Fri, Dec 16, 2011 at 4:12 AM, Sridhar Dhanapalan wrote: > We're currently evaluating 11.3.0, and I recently discovered that > Ctrl+Alt+Erase doesn't work on XO-1.5s. You are going to build your own OS image, right? We can give you a quick recipe to re-enable it. > This feature is used by teachers in the field, and by us in testing. > Its removal is a regression for us. Can you explain the use by teachers in the field? Use during testing and debugging is fine, but we all work for our end users :-) > I've updated #11202. thanks! m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Fri, Dec 16, 2011 at 08:12:27PM +1100, Sridhar Dhanapalan wrote: > On 31 August 2011 18:53, James Cameron wrote: > > On Thu, Jul 21, 2011 at 08:22:42AM +1000, James Cameron wrote: > >> On Wed, Jul 20, 2011 at 06:40:55AM -0400, Martin Langhoff wrote: > >> > Once they learn that a particular key combination "finishes" runin > >> > earlier, accidents can happen with surprising frequency. > >> > >> How is the power button being prevented? > >> > >> If the problem is that an early termination is indistinguishable from a > >> test success, why not change runin accordingly? ?I'm happy to do that if > >> needed. > > > > I didn't get an answer to my question. ?This has come up ... Bert has > > noticed that Ctrl-Alt-Erase doesn't work any more. ?#11202. ?The > > installed base obviously got used to it. ?Withdrawing a useful feature, > > even if undocumented, will cause an increase in support costs. > > > > So I've investigated the effect of Ctrl-Alt-Erase on runin. > > > > When manufacturing tag TS is set to RUNIN, runin-main will be run on > > boot, which will start the X server and execute runin-tests within it. > > > > On normal successful completion, the preserve function in runin-tests > > replaces /boot/olpc.fth with one that changes the TS tag to SHIP, in > > inject-tags. > > > > When the X server is terminated by Ctrl-Alt-Erase, runin-tests aborts > > immediately, and so the preserve function is not executed, and the > > system is then rebooted. ?On the next boot, with TS still set to RUNIN, > > the tests are restarted. > > > > The same thing happens with a battery removal or power button hold. > > > > So, when you say that this key combination "finishes" runin earlier, can > > you explain your observations further? > > > > If this was the only justification for removing the feature, then I urge > > you to reconsider, and restore the feature. > > We're currently evaluating 11.3.0, and I recently discovered that > Ctrl+Alt+Erase doesn't work on XO-1.5s. > > This feature is used by teachers in the field, and by us in testing. > Its removal is a regression for us. > > I've updated #11202. You need not block on this, you only need to configure the X server's DontZap feature back to what it was before. I think it should be restored for 11.3.1, but I'm a voice in the wilderness on this one. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On 31 August 2011 18:53, James Cameron wrote: > On Thu, Jul 21, 2011 at 08:22:42AM +1000, James Cameron wrote: >> On Wed, Jul 20, 2011 at 06:40:55AM -0400, Martin Langhoff wrote: >> > Once they learn that a particular key combination "finishes" runin >> > earlier, accidents can happen with surprising frequency. >> >> How is the power button being prevented? >> >> If the problem is that an early termination is indistinguishable from a >> test success, why not change runin accordingly? I'm happy to do that if >> needed. > > I didn't get an answer to my question. This has come up ... Bert has > noticed that Ctrl-Alt-Erase doesn't work any more. #11202. The > installed base obviously got used to it. Withdrawing a useful feature, > even if undocumented, will cause an increase in support costs. > > So I've investigated the effect of Ctrl-Alt-Erase on runin. > > When manufacturing tag TS is set to RUNIN, runin-main will be run on > boot, which will start the X server and execute runin-tests within it. > > On normal successful completion, the preserve function in runin-tests > replaces /boot/olpc.fth with one that changes the TS tag to SHIP, in > inject-tags. > > When the X server is terminated by Ctrl-Alt-Erase, runin-tests aborts > immediately, and so the preserve function is not executed, and the > system is then rebooted. On the next boot, with TS still set to RUNIN, > the tests are restarted. > > The same thing happens with a battery removal or power button hold. > > So, when you say that this key combination "finishes" runin earlier, can > you explain your observations further? > > If this was the only justification for removing the feature, then I urge > you to reconsider, and restore the feature. We're currently evaluating 11.3.0, and I recently discovered that Ctrl+Alt+Erase doesn't work on XO-1.5s. This feature is used by teachers in the field, and by us in testing. Its removal is a regression for us. I've updated #11202. Sridhar Dhanapalan Engineering Manager One Laptop per Child Australia ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Thu, Jul 21, 2011 at 08:22:42AM +1000, James Cameron wrote: > On Wed, Jul 20, 2011 at 06:40:55AM -0400, Martin Langhoff wrote: > > Once they learn that a particular key combination "finishes" runin > > earlier, accidents can happen with surprising frequency. > > How is the power button being prevented? > > If the problem is that an early termination is indistinguishable from a > test success, why not change runin accordingly? I'm happy to do that if > needed. I didn't get an answer to my question. This has come up ... Bert has noticed that Ctrl-Alt-Erase doesn't work any more. #11202. The installed base obviously got used to it. Withdrawing a useful feature, even if undocumented, will cause an increase in support costs. So I've investigated the effect of Ctrl-Alt-Erase on runin. When manufacturing tag TS is set to RUNIN, runin-main will be run on boot, which will start the X server and execute runin-tests within it. On normal successful completion, the preserve function in runin-tests replaces /boot/olpc.fth with one that changes the TS tag to SHIP, in inject-tags. When the X server is terminated by Ctrl-Alt-Erase, runin-tests aborts immediately, and so the preserve function is not executed, and the system is then rebooted. On the next boot, with TS still set to RUNIN, the tests are restarted. The same thing happens with a battery removal or power button hold. So, when you say that this key combination "finishes" runin earlier, can you explain your observations further? If this was the only justification for removing the feature, then I urge you to reconsider, and restore the feature. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
james wrote: > On Thu, Jul 21, 2011 at 12:14:14AM -0400, Martin Langhoff wrote: > > On Wed, Jul 20, 2011 at 6:04 AM, Martin Langhoff wrote: > > > On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff > > > wrote: > > >> ?- Updates olpc-utils to disable X zapping and fix serial port terminal > > > > > > Initial testing seems to indicate serial port needs a bit more > > > attention. I've also tested it with a newer kernel containing Paul's > > > tty config fix, and it doesn't make a difference. > > > > Looking at it again -- there is no apparent problem with using the > > serial port, only an early msg in var/log/messages > > > > Jul 21 04:07:36 localhost init: ttySx main process (33) terminated > > with status 1 > > I looked into this. > > /etc/init/ttyS.conf says "start on startup", but if it is changed to > "start on runlevel [12345]" this strange message goes away. Perhaps it that would probably be okay. when i changed our conf file to "start on startup" a year or more ago, it was to get the serial port up as soon as possible, because i was tired of not having it while the system booted. (it was being treated as a normal user getty before that, i think.) paul > is caused by some interaction with upstart's init, or perhaps we are not > following best practices in ttyS.conf. > > (We have our own ttyS.conf, but curiously /etc/init/serial.conf might > have been starting a process, but it says it requires ttyS2 to be the > last or primary console in the kernel command line, and for it to be > listed in /etc/securetty. Doing those things doesn't cause serial.conf > to start a process though.) > > > But nothing seems to be broken > > > > - shutdown/reboot works correctly (and the plymouth workaround has > > been removed) > > - switch to gnome / sugar works correctly > > - bash is respawned correctly if you exit > > My gut feel is that we still have something lurking here, but nothing we > ship at the moment tries modem control on /dev/ttyS2. Not even > ModemManager, according to strace. (Pity it doesn't ignore USB serial > adapters as well.) > > I looked briefly at the serial/pxa driver. When a user process > configures for modem control on /dev/ttyS2 via termios, the upshot is > the setting of bit AFE (Auto-flow Control Enable) in the UART MCR (modem > control register). Good. > > During serial_pxa_startup, /dev/ttyS3 is configured for AFE > automatically. But I didn't see any obvious way at mmp2_add_uart time > to tell the driver not to bother setting UART_MCR_AFE for /dev/ttyS2. > > The control lines themselves aren't exposed, which is presumably why > threads that do I/O hang. > > But hey, the same thing happens on XO-1.5, just tested ... so we're good > to go. ;-) > > -- > James Cameron > http://quozl.linux.org.au/ > ___ > Techteam mailing list > techt...@lists.laptop.org > http://lists.laptop.org/listinfo/techteam > ___ > Engineering mailing list > engineer...@laptop.org > http://lists.laptop.org/listinfo/engineering =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New F14-arm build os21
On Thu, Jul 21, 2011 at 12:14:14AM -0400, Martin Langhoff wrote: > On Wed, Jul 20, 2011 at 6:04 AM, Martin Langhoff wrote: > > On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff wrote: > >> ?- Updates olpc-utils to disable X zapping and fix serial port terminal > > > > Initial testing seems to indicate serial port needs a bit more > > attention. I've also tested it with a newer kernel containing Paul's > > tty config fix, and it doesn't make a difference. > > Looking at it again -- there is no apparent problem with using the > serial port, only an early msg in var/log/messages > > Jul 21 04:07:36 localhost init: ttySx main process (33) terminated > with status 1 I looked into this. /etc/init/ttyS.conf says "start on startup", but if it is changed to "start on runlevel [12345]" this strange message goes away. Perhaps it is caused by some interaction with upstart's init, or perhaps we are not following best practices in ttyS.conf. (We have our own ttyS.conf, but curiously /etc/init/serial.conf might have been starting a process, but it says it requires ttyS2 to be the last or primary console in the kernel command line, and for it to be listed in /etc/securetty. Doing those things doesn't cause serial.conf to start a process though.) > But nothing seems to be broken > > - shutdown/reboot works correctly (and the plymouth workaround has > been removed) > - switch to gnome / sugar works correctly > - bash is respawned correctly if you exit My gut feel is that we still have something lurking here, but nothing we ship at the moment tries modem control on /dev/ttyS2. Not even ModemManager, according to strace. (Pity it doesn't ignore USB serial adapters as well.) I looked briefly at the serial/pxa driver. When a user process configures for modem control on /dev/ttyS2 via termios, the upshot is the setting of bit AFE (Auto-flow Control Enable) in the UART MCR (modem control register). Good. During serial_pxa_startup, /dev/ttyS3 is configured for AFE automatically. But I didn't see any obvious way at mmp2_add_uart time to tell the driver not to bother setting UART_MCR_AFE for /dev/ttyS2. The control lines themselves aren't exposed, which is presumably why threads that do I/O hang. But hey, the same thing happens on XO-1.5, just tested ... so we're good to go. ;-) -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New F14-arm build os21
On Wed, Jul 20, 2011 at 6:04 AM, Martin Langhoff wrote: > On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff wrote: >> - Updates olpc-utils to disable X zapping and fix serial port terminal > > Initial testing seems to indicate serial port needs a bit more > attention. I've also tested it with a newer kernel containing Paul's > tty config fix, and it doesn't make a difference. Looking at it again -- there is no apparent problem with using the serial port, only an early msg in var/log/messages Jul 21 04:07:36 localhost init: ttySx main process (33) terminated with status 1 But nothing seems to be broken - shutdown/reboot works correctly (and the plymouth workaround has been removed) - switch to gnome / sugar works correctly - bash is respawned correctly if you exit So an excellent cleanup. Thanks to James and Paul for this! BTW, not sure what crossed my mind when I penned the announcement email -- it's a F13 image. Alas, what a disappointment. F14 images are pretty close however. m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Wed, Jul 20, 2011 at 06:40:55AM -0400, Martin Langhoff wrote: > Once they learn that a particular key combination "finishes" runin > earlier, accidents can happen with surprising frequency. How is the power button being prevented? If the problem is that an early termination is indistinguishable from a test success, why not change runin accordingly? I'm happy to do that if needed. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New F14-arm build os21
On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff wrote: > Use with OFW Q4B02: > > http://wiki.laptop.org/go/OLPC_Firmware_q4b02 Wad points out I am seriously out of date w my OFW recommendations. Please use Q4B05 http://wiki.laptop.org/go/OLPC_Firmware_q4b05 m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
On Wed, Jul 20, 2011 at 6:19 AM, Paul Fox wrote: > what's the "X zapping" part of this? unfamiliar with the reference. "DontZap" is the xorg.conf option to disable ctrl-alt-backspace. I've updated olpc-utils to use that option, so that operators in the prod line don't accidentally hit it. Once they learn that a particular key combination "finishes" runin earlier, accidents can happen with surprising frequency. m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [OLPC Engineering] [Techteam] New F14-arm build os21
martin wrote: > On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff wrote: > > - Updates olpc-utils to disable X zapping and fix serial port terminal > > Initial testing seems to indicate serial port needs a bit more > attention. I've also tested it with a newer kernel containing Paul's > tty config fix, and it doesn't make a difference. > > Haven't had time to diagnose yet - what's the "X zapping" part of this? unfamiliar with the reference. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New F14-arm build os21
On Wed, Jul 20, 2011 at 6:02 AM, Martin Langhoff wrote: > - Updates olpc-utils to disable X zapping and fix serial port terminal Initial testing seems to indicate serial port needs a bit more attention. I've also tested it with a newer kernel containing Paul's tty config fix, and it doesn't make a difference. Haven't had time to diagnose yet - cheers, m -- mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New F14-arm build os21
The "Fix serial TTY and tighten runin" build.
Donwload from:
http://build.laptop.org/F13-arm/os21/
Use with OFW Q4B02:
http://wiki.laptop.org/go/OLPC_Firmware_q4b02
Changes:
- Updates olpc-runin-tests to the version we are using during B1 build.
- Updates olpc-utils to disable X zapping and fix serial port terminal
Kernel changelog:
Jonathan Corbet (6):
marvell-cam: delete struct mcam_sio_buffer
marvell-cam: core code reorganization
marvell-cam: remove {min,max}_buffers parameters
marvell-cam: power down mmp camera on registration failure
marvell-cam: Allow selection of supported buffer modes
marvell-cam: clean up a couple of unused cam structure fields
Paul Fox (5):
handle 16-bit XO-1.75 board ID values correctly
implement the input driver for the XO-1.75 power button
rationalize use of the EC driver's name in dmesg output
implement input driver support for 1.75 lid and ebook switches
disable /dev/ttyS0 and enable /dev/ttyS3 by default on XO-1.75
m
--
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
