Custom Search
|
Date: August 31, 2006
From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
In-reply-to:
<200608311713.21618.bjorn.helgaas@xxxxxx>
References:
<EB12A50964762B4D8111D55B764A845484D316@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20060830194317.GA9116@xxxxxxxxxxxxx> <200608311713.21618.bjorn.helgaas@xxxxxx>
On Thu, Aug 31, 2006 at 05:13:20PM -0600, Bjorn Helgaas wrote: > Out of curiosity, what is the motivation for running without acpi? > It costs a lot to diverge from the mainstream in areas like that, > so there must be a big payoff. But maybe if OLPC depends on acpi > being smarter about power or code size or whatever, those improvements > could be made and everybody would benefit. The current issues are probably the code size and the somewhat specialised needs of OLPC. The hardware is interesting in that the framebuffer is designed to carry on reading from memory even if the rest of the system is in S3. The aim here is to allow the machine to suspend when idle while still giving the impression of being alive. It's therefore important that the system come out of suspend as quickly as possible in order to avoid spoiling that impression, and suspend as quickly as possible in order to maximise the power savings. The assumption is that parsing AML is something that would add to these time periods without providing any significant extra benefit. Of course, the other main issue is that providing an ACPI platform would require us to actually write a set of ACPI tables. The system is running Linuxbios, and every kilobyte that's not used by a static table in the BIOS is space that could be used for extra functionality. I think the basic consensus was that ACPI bought us fairly little other than the ability to use the existing suspend/resume code, C state transitions and battery monitoring, and that replacing the first was probably desirable in any case. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx
Date: August 31, 2006
From: Bjorn Helgaas <bjorn.helgaas@xxxxxx>
In-reply-to:
<20060830194317.GA9116@xxxxxxxxxxxxx>
References:
<EB12A50964762B4D8111D55B764A845484D316@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20060830194317.GA9116@xxxxxxxxxxxxx>
On Wednesday 30 August 2006 13:43, Matthew Garrett wrote: > That would be helpful. For the One Laptop Per Child project (or whatever > it's called today), it would be advantageous to run without acpi. Out of curiosity, what is the motivation for running without acpi? It costs a lot to diverge from the mainstream in areas like that, so there must be a big payoff. But maybe if OLPC depends on acpi being smarter about power or code size or whatever, those improvements could be made and everybody would benefit. - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Date: August 31, 2006
From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
In-reply-to:
<20060831170549.GB2838@dmt
>
References:
<1156900799.15339.55.camel@xxxxxxxxxxxxxxxxxxx> <20060830025442.GA8473@dmt
> <1157037778.2516.25.camel@xxxxxxxxxxxxxxxxxxxxxxx> <20060831170549.GB2838@dmt
>
On Thu, 2006-08-31 at 14:05 -0300, Marcelo Tosatti wrote: > On Thu, Aug 31, 2006 at 08:22:57AM -0700, David Woodhouse wrote: > > On Tue, 2006-08-29 at 23:54 -0300, Marcelo Tosatti wrote: > > > * Condition CONFIG_GC_SECTIONS on presence of a recent binutils > > > > Er, I missed something -- why does this need a recent binutils? We've > > been building kernels with --gc-sections for years, at least on some > > platforms. > > First, I think its prudent to guarantee that a well behaved version of > binutils (wrt. garbage collection) is being used. No? Are recent versions of binutils known to misbehave? It's not as if --gc-sections is a new thing. > Second reason is the newly added --print-gc-sections option, which: ... needs to be a CONFIG option anyway so _that_ CONFIG option can require the new binutils. > 2) Its very useful for developers to > > - Debug breakage caused by gc-section misbehaviour. > - Easily check what symbols are being swept. Some people will care -- many won't, but might want to build with --gc-sections anyway. No reason not to let them do so, surely? Just require new binutils if you want the --print-gc-sections stuff. -- dwmw2
Date: August 31, 2006
From: Jim Gettys <jg@xxxxxxxxxx>
In-reply-to:
<44F72256.5010401@xxxxxxx>
References:
<44F72256.5010401@xxxxxxx>
On Thu, 2006-08-31 at 19:54 +0200, Carl-Daniel Hailfinger wrote:
> Hi,
>
> while watching the GPL compliance effort put into buildrom, I asked
> myself whether we have any documentation about the licenses of the
> VSA code and the EC code. IIRC some of us have/had access to the
> VSA source but lack a working compiler for it.
Neither the EC nor VSA are linked into Linux or LinuxBIOS; I think we
are clear of the GPL in any case and that technically, no source has to
be provided for either. All that we are doing is making a compilation
of different pieces (literally by concatenation). The GPL requires that
any GPL'ed code be made available. So what we do have to do is make the
Linux/LinuxBIOS code available when we make the binaries available.
We intend to make source available to the EC and VSA in any case, when
we get all our ducks in a row (Jordan, what's the state of the VSA
code?).
Even if we did have to make the VSA available right now, the GPL turns
out not to require that you make the tools required to build the
binaries available.
>
> This mail is just to get some feedback. If appropriate, I'll create
> a trac ticket later.
Thanks. We do need to keep track of this stuff. I learned more about
the GPL than I cared to on the iPAQ project.
- Jim
--
Jim Gettys
One Laptop Per Child
Date: August 31, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<037.48f9e4aa2e39869014e43d2bc34c7bac@xxxxxxxxxx>
References:
<037.48f9e4aa2e39869014e43d2bc34c7bac@xxxxxxxxxx>
#78: Wireless driver sometimes fails to bind to enumerated device
--------------------+-------------------------------------------------------
Reporter: cjb | Owner: marcelo
Type: defect | Status: closed
Priority: high | Milestone: rev1 beta
Component: kernel | Resolution: fixed
Keywords: |
--------------------+-------------------------------------------------------
Changes (by cjb):
* status: new => closed
* resolution: => fixed
Comment:
After disabling my USB ethernet module (pegasus.ko), I haven't seen this
during 15 warm reboots and a couple of cold ones. Closing for now, will
reopen if it happens again.
--
Ticket URL: <http://dev.laptop.org/ticket/78#comment:3>
One Laptop Per Child <http://laptop.org/>
Date: August 31, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<046.b2dd469a43d64a74cad87ebeb09c554d@xxxxxxxxxx>
References:
<046.b2dd469a43d64a74cad87ebeb09c554d@xxxxxxxxxx>
#46: Eliminate dependency on licensed code in Marvell firmware.
-------------------------+--------------------------------------------------
Reporter: jg | Owner: mfoster
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: hardware | Resolution:
Keywords: |
-------------------------+--------------------------------------------------
Comment (by mfoster):
Hi, Marcelo!
Actually, we'll have no problem getting started under NDA. Once that's in
place for the core developers, we'd then move to an alternate O.S., and we
could then be truly Open Source.
Cheers!
MarkF
P.S. This should actually be assigned to mbletsas@xxxxxxxxxx, but he
doesn't have a Trac account yet.
--
Ticket URL: <http://dev.laptop.org/ticket/46#comment:2>
One Laptop Per Child <http://laptop.org/>
Date: August 31, 2006
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@xxxxxxx>
Hi, while watching the GPL compliance effort put into buildrom, I asked myself whether we have any documentation about the licenses of the VSA code and the EC code. IIRC some of us have/had access to the VSA source but lack a working compiler for it. This mail is just to get some feedback. If appropriate, I'll create a trac ticket later. Regards, Carl-Daniel -- http://www.hailfinger.org/
Date: August 31, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<037.48f9e4aa2e39869014e43d2bc34c7bac@xxxxxxxxxx>
References:
<037.48f9e4aa2e39869014e43d2bc34c7bac@xxxxxxxxxx>
#78: Wireless driver sometimes fails to bind to enumerated device
--------------------+-------------------------------------------------------
Reporter: cjb | Owner: marcelo
Type: defect | Status: new
Priority: high | Milestone: rev1 beta
Component: kernel | Resolution:
Keywords: |
--------------------+-------------------------------------------------------
Comment (by cjb):
Both `cat /proc/bus/usb/devices` and `modprobe usb8xxx` hang (!).
USB isn't down, though; my USB keyboard (on a powered hub) and USB flash
disk (directly attached) still work.
--
Ticket URL: <http://dev.laptop.org/ticket/78#comment:2>
One Laptop Per Child <http://laptop.org/>
Date: August 31, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<046.28855506fe04f0064a14786704ead324@xxxxxxxxxx>
References:
<046.28855506fe04f0064a14786704ead324@xxxxxxxxxx>
#78: Wireless driver sometimes fails to bind to enumerated device
--------------------+-------------------------------------------------------
Reporter: cjb | Owner: marcelo
Type: defect | Status: new
Priority: high | Milestone: rev1 beta
Component: kernel | Resolution:
Keywords: |
--------------------+-------------------------------------------------------
Changes (by marcelo):
* owner: blizzard => marcelo
--
Ticket URL: <http://dev.laptop.org/ticket/78#comment:1>
One Laptop Per Child <http://laptop.org/>
Date: August 31, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<037.4caa9ee1cc0cf9e106329583ddff8437@xxxxxxxxxx>
References:
<037.4caa9ee1cc0cf9e106329583ddff8437@xxxxxxxxxx>
#46: Eliminate dependency on licensed code in Marvell firmware.
-------------------------+--------------------------------------------------
Reporter: jg | Owner: mfoster
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: hardware | Resolution:
Keywords: |
-------------------------+--------------------------------------------------
Comment (by marcelo):
Requires documentation/cooperation from Marvell about the internal
workings of the chip.
Are they willing to go that route?
--
Ticket URL: <http://dev.laptop.org/ticket/46#comment:1>
One Laptop Per Child <http://laptop.org/>
Date: August 31, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<042.577fc928f885b965b7c2102003f84b76@xxxxxxxxxx>
References:
<042.577fc928f885b965b7c2102003f84b76@xxxxxxxxxx>
#59: Marvell wireless won't run from LinuxBIOS
-------------------------------+--------------------------------------------
Reporter: wmb@xxxxxxxxxxxxx | Owner: JordanCrouse
Type: defect | Status: closed
Priority: blocker | Milestone:
Component: display | Resolution: fixed
Keywords: |
-------------------------------+--------------------------------------------
Changes (by marcelo):
* status: new => closed
* resolution: => fixed
--
Ticket URL: <http://dev.laptop.org/ticket/59#comment:3>
One Laptop Per Child <http://laptop.org/>
Date: August 31, 2006
From: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
In-reply-to:
<1156906663.22848.1.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<1156900799.15339.55.camel@xxxxxxxxxxxxxxxxxxx> <20060830025442.GA8473@dmt
> <1156906663.22848.1.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Tue, Aug 29, 2006 at 07:57:43PM -0700, Daniel Walker wrote: > On Tue, 2006-08-29 at 23:54 -0300, Marcelo Tosatti wrote: > > > However, latest patch is still http://lkml.org/lkml/2006/6/4/169 > > > > Current TODO: > > > > * Condition CONFIG_GC_SECTIONS on presence of a recent binutils > > * Extra config option to allow for non used exported symbols to be swept > > (must be > > non default behaviour) > > * Recursive make invocation from Makefile is sort of ugly, Makefile changes > > can beautified. > > * Do the same as done for ksymtab* to kcrctab* (CONFIG_MODVERSIONS) > > * Cover other architectures with KEEP() directives * Use -fdata-sections
Date: August 31, 2006
From: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
In-reply-to:
<1157037778.2516.25.camel@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<1156900799.15339.55.camel@xxxxxxxxxxxxxxxxxxx> <20060830025442.GA8473@dmt
> <1157037778.2516.25.camel@xxxxxxxxxxxxxxxxxxxxxxx>
On Thu, Aug 31, 2006 at 08:22:57AM -0700, David Woodhouse wrote: > On Tue, 2006-08-29 at 23:54 -0300, Marcelo Tosatti wrote: > > * Condition CONFIG_GC_SECTIONS on presence of a recent binutils > > Er, I missed something -- why does this need a recent binutils? We've > been building kernels with --gc-sections for years, at least on some > platforms. First, I think its prudent to guarantee that a well behaved version of binutils (wrt. garbage collection) is being used. No? Second reason is the newly added --print-gc-sections option, which: 1) Is used unconditially by the current patch to find out which symbols have been swept. Such are matched against the list of used symbols used by compiled modules in the current build, so that the linker can discard exported but unused functions (and their respective entries in ksymtab/kcrctab sections). As you mentioned in the past, that breaks out-of-tree/later compiled modules, but a vast amount of users never do that (eg embedded systems). So that behaviour needs to be conditional on a new CONFIG option. 2) Its very useful for developers to - Debug breakage caused by gc-section misbehaviour. - Easily check what symbols are being swept. But I don't have a very strong opinion here, just arguments in favour of it.
Date: August 31, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<034.d14301b1100ede93d246e6ccc99bff73@xxxxxxxxxx>
References:
<034.d14301b1100ede93d246e6ccc99bff73@xxxxxxxxxx>
#77: jhbuild failure on Ubuntu
--------------------+-------------------------------------------------------
Reporter: ianb | Owner: dcbw
Type: defect | Status: new
Priority: normal | Milestone: rev1 beta
Component: sugar | Resolution:
Keywords: |
--------------------+-------------------------------------------------------
Old description:
> Running sugar-jhbuild build on Ubuntu Dapper, two modules fail to build
> properly for me: matchbox and goocanvas. (I also had to install the
> "gtk-doc-tools" package to get another module to build). Here are the
> errors:
>
> ~/src/ext/sugar-jhbuild/source/matchbox-window-manager
> l$ ./autogen.sh --prefix /home/ianb/src/ext/sugar-jhbuild/build
> --disable-static --disable-gtk-doc
> autoreconf: Entering directory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal --output=aclocal.m4t
> autoreconf: `aclocal.m4' is unchanged
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: not using Libtool
> autoreconf: running: /usr/bin/autoconf
> autoreconf: running: /usr/bin/autoheader
> autoreconf: running: automake --add-missing --copy
> configure.ac: 7: required file `./[config.h].in' not found
> data/schemas/Makefile.am:3: GCONF_SCHEMAS_INSTALL does not appear in
> AM_CONDITIONAL
> autoreconf: automake failed with exit status: 1
>
>
>
> l$ ./autogen.sh --prefix /home/ianb/src/ext/sugar-jhbuild/build
> --disable-static --disable-gtk-doc
> processing .
> Creating ./aclocal.m4 ...
> Running glib-gettextize... Ignore non-fatal messages.
> Copying file mkinstalldirs
> Copying file po/Makefile.in.in
>
> Please add the files
> codeset.m4 gettext.m4 glibc21.m4 iconv.m4 isc-posix.m4 lcmessage.m4
> progtest.m4
> from the /usr/share/aclocal directory to your autoconf macro directory
> or directly to your aclocal.m4 file.
> You will also need config.guess and config.sub, which you can get from
> ftp://ftp.gnu.org/pub/gnu/config/.
>
> Making ./aclocal.m4 writable ...
> Running libtoolize...
> Running aclocal ...
> Running autoheader...
> Running automake --gnu ...
> configure.in: 6: `automake requires `AM_CONFIG_HEADER', not
> `AC_CONFIG_HEADER'
> Makefile.am:6: require version 1.7, but have 1.4-p6
> docs/Makefile.am:4: require version 1.6, but have 1.4-p6
> Running autoconf ...
> Running ./configure --enable-maintainer-mode --prefix /home/ianb/src/ext
> /sugar-jhbuild/build --disable-static --disable-gtk-doc ...
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking whether make sets $(MAKE)... yes
> checking for working aclocal-1.4... found
> checking for working autoconf... found
> checking for working automake-1.4... found
> checking for working autoheader... found
> checking for working makeinfo... found
> checking whether to enable maintainer-specific portions of Makefiles...
> yes
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ANSI C... none needed
> checking for strerror in -lcposix... no
> checking for gcc... (cached) gcc
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether gcc accepts -g... (cached) yes
> checking for gcc option to accept ANSI C... (cached) none needed
> checking how to run the C preprocessor... gcc -E
> checking for egrep... grep -E
> checking for ANSI C header files... yes
> checking build system type... i686-pc-linux-gnu
> checking host system type... i686-pc-linux-gnu
> checking for a sed that does not truncate output... /bin/sed
> checking for ld used by gcc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for /usr/bin/ld option to reload object files... -r
> checking for BSD-compatible nm... /usr/bin/nm -B
> checking whether ln -s works... yes
> checking how to recognise dependent libraries... pass_all
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking dlfcn.h usability... yes
> checking dlfcn.h presence... yes
> checking for dlfcn.h... yes
> checking for g++... g++
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking how to run the C++ preprocessor... g++ -E
> checking for g77... no
> checking for f77... no
> checking for xlf... no
> checking for frt... no
> checking for pgf77... no
> checking for fort77... no
> checking for fl32... no
> checking for af77... no
> checking for f90... no
> checking for xlf90... no
> checking for pgf90... no
> checking for epcf90... no
> checking for f95... no
> checking for fort... no
> checking for xlf95... no
> checking for ifc... no
> checking for efc... no
> checking for pgf95... no
> checking for lf95... no
> checking for gfortran... no
> checking whether we are using the GNU Fortran 77 compiler... no
> checking whether accepts -g... no
> checking the maximum length of command line arguments... 32768
> checking command to parse /usr/bin/nm -B output from gcc object... ok
> checking for objdir... .libs
> checking for ar... ar
> checking for ranlib... ranlib
> checking for strip... strip
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC
> checking if gcc PIC flag -fPIC works... yes
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking whether the gcc linker (/usr/bin/ld) supports shared
> libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... no
> configure: creating libtool
> appending configuration tag "CXX" to libtool
> checking for ld used by g++... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking whether the g++ linker (/usr/bin/ld) supports shared
> libraries... yes
> checking for g++ option to produce PIC... -fPIC
> checking if g++ PIC flag -fPIC works... yes
> checking if g++ static flag -static works... yes
> checking if g++ supports -c -o file.o... yes
> checking whether the g++ linker (/usr/bin/ld) supports shared
> libraries... yes
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> appending configuration tag "F77" to libtool
> checking for pkg-config... /usr/bin/pkg-config
> checking pkg-config is at least version 0.9.0... yes
> checking for PACKAGE... yes
> checking locale.h usability... yes
> checking locale.h presence... yes
> checking for locale.h... yes
> checking for LC_MESSAGES... yes
> checking libintl.h usability... yes
> checking libintl.h presence... yes
> checking for libintl.h... yes
> checking for ngettext in libc... yes
> checking for dgettext in libc... yes
> checking for bind_textdomain_codeset... yes
> checking for msgfmt... /usr/bin/msgfmt
> checking for dcgettext... yes
> checking for gmsgfmt... /usr/bin/msgfmt
> checking for xgettext... /usr/bin/xgettext
> checking for catalogs to be installed... en_GB
> checking for glib-genmarshal... glib-genmarshal
> configure: creating ./config.status
> config.status: error: cannot find input file: Makefile.in
New description:
Running sugar-jhbuild build on Ubuntu Dapper, two modules fail to build
properly for me: matchbox and goocanvas. (I also had to install the "gtk-
doc-tools" package to get another module to build). Attached are the
errors.
Comment (by ianb):
That comment wasn't very readable, so I've attached a text version of the
build errors
--
Ticket URL: <http://dev.laptop.org/ticket/77#comment:1>
One Laptop Per Child <http://laptop.org/>
Date: August 31, 2006
From: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
In-reply-to:
<20060830025442.GA8473@dmt
>
References:
<1156900799.15339.55.camel@xxxxxxxxxxxxxxxxxxx> <20060830025442.GA8473@dmt
>
On Tue, 2006-08-29 at 23:54 -0300, Marcelo Tosatti wrote: > * Condition CONFIG_GC_SECTIONS on presence of a recent binutils Er, I missed something -- why does this need a recent binutils? We've been building kernels with --gc-sections for years, at least on some platforms. -- dwmw2
Date: August 31, 2006
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@xxxxxxx>
In-reply-to:
<e8ac1af10608310636g2e940e53jb95619b2372d1571@xxxxxxxxxxxxxx>
References:
<1156867338.5961.55.camel@xxxxxxxxxxxxxxxxxxxxx> <20060830083144.GJ6174@xxxxxxxxxxxxxxxxxx> <e8ac1af10608310239x6920bc05u6582746ff70f6ac5@xxxxxxxxxxxxxx> <44F6C0CE.50107@xxxxxxx> <e8ac1af10608310636g2e940e53jb95619b2372d1571@xxxxxxxxxxxxxx>
Tushar Adeshara wrote: > On 8/31/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@xxxxxxx> > wrote: >> Tushar Adeshara wrote: >> > On 8/30/06, Joshua N Pritikin <jpritikin@xxxxxxxxx> wrote: >> >> On Tue, Aug 29, 2006 at 12:02:18PM -0400, Jim Gettys wrote: >> >> > "Belt and Suspenders" feels right to me. >> >> >> >> Even if kids are going to blindly follow directions about "Hold this >> >> key combo >> >> down to reflash the BIOS", that's good because then they'll know that >> >> _something_ is happening. Mystery invites investigation. More kids >> will >> >> discover the BIOS and its humble purpose. >> > >> > I think we need to also think about situations where there will be >> > many such laptops (100 to 500) that need BIOS update. Best way to do >> > that here would be no physical interaction with machine for BIOS >> > update. >> >> At some school: "Hey kids, please press spacebar now!" >> >> Laptops are inteded to stay with the kids all the time. BIOS updates >> should hopefully be something needed at most once or twice, unlike >> regurlar kernel updates. So telling kids once in their lifetime to >> press a specific button while they are at school is no significant >> problem. > > I suggested something that I would like in a device if I have to > ensure that all laptops are updated. If we require physical > interaction for BIOS updates, we ensure that updates can't be > automated if need arises later on. > > I would like to know about problems you can think of with the above > approach. It has already been written in this thread a few mails ago, but let me repeat: * BIOS updates are only needed in case of incorrect hardware setup * This will not happen regularly * Automation has the potential to brick thousands of machines overnight And now the most important point: * OLPC was designed to make your scenario (service center where hundreds of machines are reflashed/updated) unneeded If we suddenly find out that machines need an update, it will affect not only a few hundred machines, but something like a million machines. You can't rely on the mesh network to reach every machine at the same time (and many meshes will be completely disconnected from the rest of the world), so you have to visit schools anyway. And then there is really no problem telling kids to press a key. Regards, Carl-Daniel -- http://www.hailfinger.org/
Date: August 31, 2006
From: "Tushar Adeshara" <adesharatushar@xxxxxxxxx>
In-reply-to:
<44F6C0CE.50107@xxxxxxx>
References:
<1156867338.5961.55.camel@xxxxxxxxxxxxxxxxxxxxx> <20060830083144.GJ6174@xxxxxxxxxxxxxxxxxx> <e8ac1af10608310239x6920bc05u6582746ff70f6ac5@xxxxxxxxxxxxxx> <44F6C0CE.50107@xxxxxxx>
On 8/31/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@xxxxxxx> wrote:
Tushar Adeshara wrote: > On 8/30/06, Joshua N Pritikin <jpritikin@xxxxxxxxx> wrote: >> On Tue, Aug 29, 2006 at 12:02:18PM -0400, Jim Gettys wrote: >> > "Belt and Suspenders" feels right to me. >> >> Even if kids are going to blindly follow directions about "Hold this >> key combo >> down to reflash the BIOS", that's good because then they'll know that >> _something_ is happening. Mystery invites investigation. More kids will >> discover the BIOS and its humble purpose. > > I think we need to also think about situations where there will be > many such laptops (100 to 500) that need BIOS update. Best way to do > that here would be no physical interaction with machine for BIOS > update. At some school: "Hey kids, please press spacebar now!" Laptops are inteded to stay with the kids all the time. BIOS updates should hopefully be something needed at most once or twice, unlike regurlar kernel updates. So telling kids once in their lifetime to press a specific button while they are at school is no significant problem.
I suggested something that I would like in a device if I have to ensure that all laptops are updated. If we require physical interaction for BIOS updates, we ensure that updates can't be automated if need arises later on. I would like to know about problems you can think of with the above approach. It looks to solve problem of automated BIOS updates (when it is from OLPC), protection against phishing attacks for child and allows developer to use his own BIOS code. Regards, Tushar -------------------- It's not a problem, it's an opportunity for improvement. Lets improve.
Date: August 31, 2006
From: "Marcos Barbosa" <marcosestevesbarbosa@xxxxxxxxx>
In-reply-to:
<20060831012401.GA2754@dmt
>
References:
<42bbb5c30608300529r1536f282v605773d7012e52ad@xxxxxxxxxxxxxx> <44F585AC.60101@xxxxxxxxxxxxxxxxxxxxxxxxx> <42bbb5c30608300547p1bf8ea55gad78f7a568ade484@xxxxxxxxxxxxxx> <44F58BED.1090208@xxxxxxxxxxxxxxxxxxxxxxxxx> <42bbb5c30608300604q6055c50ehfff440dd8c55cdd8@xxxxxxxxxxxxxx> <20060831012401.GA2754@dmt
>
Hi! Driver detect the card, but if i reset the driver is not loaded anymore. This problem is with first release. I download the Mesh driver in Marvell website, but i can't compile. I make verious thing to correct, but the terrible error is the variable IEEE80211_RADIOTAP_RX_FLAGS is underclared. I try include in the file (wlan_rx.c) a define line, but i not know the value (i try 14 but very problems is reported and driver reset USB, wifi, etc.). And others errors is: Makefile incorrect (no target declared) Variables undeclared (others variables, because nos exist include line in the source file). Questions: What is value to variable IEEE80211_RADIOTAP_RX_FLAGS? Differences between Mesh Routing Protocol (MRP) and Forwarding Table (FWT) How to compile driver without errors Thanks for all! 2006/8/30, Marcelo Tosatti <mtosatti@xxxxxxxxxx>:
On Wed, Aug 30, 2006 at 10:04:21AM -0300, Marcos Barbosa wrote: > Thanks. You know why i report wifi network card driver bugs? Ola Marcos, Are you completly sure that the network driver does not detect your card? Issue is that, upon a failure in an attempt to load the firmware, the driver will reset the wifi device, then reset the USB connection, and retry (which is flawless from my experience, even though it reports "usb8xxx: probe of 1-4:1.0 failed with error -12" once or twice). Can you please confirm that, after the initial failed probe report, "iwconfig" reports no presence of the wifi device? Thanks. > 2006/8/30, Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx>: > >Marcos Barbosa wrote: > >> Sorry. This is rev-B board (with serial number). > > > >We haven't shipped rev-B boards yet. If you got it through the standard > >developer program, it's a rev-A. > > > >> I use default BIOS version. > > > >Okay, so you're still using the Insyde BIOS (the one with the white > >bootup screen and the big Insyde logo)? > > > >If so, I would suggest you wait a few days. We're trying to push out a > >LinuxBIOS release today or tomorrow. We can look at the issue if it > >persists after you upgrade. > > > >-- > >Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx> | GPG: 0x147C722D > > > > > -- > Abraços > Marcos Henrique Esteves Barbosa > marcosestevesbarbosa@xxxxxxxxx > _______________________________________________ > Devel mailing list > Devel@xxxxxxxxxx > http://mailman.laptop.org/mailman/listinfo/devel
-- Abraços Marcos Henrique Esteves Barbosa marcosestevesbarbosa@xxxxxxxxx
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: August 31, 2006
From: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@xxxxxxx>
In-reply-to:
<e8ac1af10608310239x6920bc05u6582746ff70f6ac5@xxxxxxxxxxxxxx>
References:
<1156867338.5961.55.camel@xxxxxxxxxxxxxxxxxxxxx> <20060830083144.GJ6174@xxxxxxxxxxxxxxxxxx> <e8ac1af10608310239x6920bc05u6582746ff70f6ac5@xxxxxxxxxxxxxx>
Tushar Adeshara wrote: > On 8/30/06, Joshua N Pritikin <jpritikin@xxxxxxxxx> wrote: >> On Tue, Aug 29, 2006 at 12:02:18PM -0400, Jim Gettys wrote: >> > "Belt and Suspenders" feels right to me. >> >> Even if kids are going to blindly follow directions about "Hold this >> key combo >> down to reflash the BIOS", that's good because then they'll know that >> _something_ is happening. Mystery invites investigation. More kids will >> discover the BIOS and its humble purpose. > > I think we need to also think about situations where there will be > many such laptops (100 to 500) that need BIOS update. Best way to do > that here would be no physical interaction with machine for BIOS > update. At some school: "Hey kids, please press spacebar now!" Laptops are inteded to stay with the kids all the time. BIOS updates should hopefully be something needed at most once or twice, unlike regurlar kernel updates. So telling kids once in their lifetime to press a specific button while they are at school is no significant problem. Regards, Carl-Daniel -- http://www.hailfinger.org/
Date: August 31, 2006
From: "Tushar Adeshara" <adesharatushar@xxxxxxxxx>
In-reply-to:
<20060830083144.GJ6174@xxxxxxxxxxxxxxxxxx>
References:
<1156867338.5961.55.camel@xxxxxxxxxxxxxxxxxxxxx> <20060830083144.GJ6174@xxxxxxxxxxxxxxxxxx>
On 8/30/06, Joshua N Pritikin <jpritikin@xxxxxxxxx> wrote:
On Tue, Aug 29, 2006 at 12:02:18PM -0400, Jim Gettys wrote: > "Belt and Suspenders" feels right to me. Even if kids are going to blindly follow directions about "Hold this key combo down to reflash the BIOS", that's good because then they'll know that _something_ is happening. Mystery invites investigation. More kids will discover the BIOS and its humble purpose.
I think we need to also think about situations where there will be many such laptops (100 to 500) that need BIOS update. Best way to do that here would be no physical interaction with machine for BIOS update. Think of it, you are the one responsible for updating every software of laptop including BIOS, and there are 500 laptops. I will prefer a shell script instead of pressing buttons of 500 laptops. For security, I agree with signing of BIOS code, but we must have some way to allow user to update his own BIOS update. Can we have some dip switch or something like that, which requires user to open laptop and change it, if he want his own BIOS code? We generally don't expect child to open laptop and change status of dip switch, but for developers it shouldn't be difficult. Thanks and Regards, Tushar Adeshara
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFE9UzwqcqnlKSmC70RAjFFAKC46psSIkREAhcG+h71SZzJYgNuawCfW8WV F7aAL64E3z2T/tobJhRsBBk= =Aqgy -----END PGP SIGNATURE----- _______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
-- Regards, Tushar -------------------- It's not a problem, it's an opportunity for improvement. Lets improve.
Date: August 31, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<032.4ab39aef00371753ef18344fbabd3b21@xxxxxxxxxx>
References:
<032.4ab39aef00371753ef18344fbabd3b21@xxxxxxxxxx>
#74: Better un-writeprotect needed
--------------------+-------------------------------------------------------
Reporter: tsylla | Owner: jg
Type: defect | Status: new
Priority: normal | Milestone:
Component: distro | Resolution:
Keywords: |
--------------------+-------------------------------------------------------
Comment (by tsylla):
dummy note to get a mail sent out
--
Ticket URL: <http://dev.laptop.org/ticket/74#comment:1>
One Laptop Per Child <http://laptop.org/>
Date: August 31, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<032.85a567a689e5a9b48604998718986270@xxxxxxxxxx>
References:
<032.85a567a689e5a9b48604998718986270@xxxxxxxxxx>
#73: rdmsr does not fail if msr module is not present
--------------------+-------------------------------------------------------
Reporter: tsylla | Owner: jg
Type: defect | Status: new
Priority: normal | Milestone:
Component: distro | Resolution:
Keywords: |
--------------------+-------------------------------------------------------
Comment (by tsylla):
dummy note to get a mail sent out
--
Ticket URL: <http://dev.laptop.org/ticket/73#comment:1>
One Laptop Per Child <http://laptop.org/>
Date: August 31, 2006
From: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
In-reply-to:
<000e01c6c303$dd68d0f0$4001a8c0@VaioTX
>
References:
<000e01c6c303$dd68d0f0$4001a8c0@VaioTX
>
On Fri, Aug 18, 2006 at 04:21:18PM -0400, Zach Jones wrote: > Hello, > > > > My name is Zach Jones and I am the CEO of a non-profit medical device > company start-up out of duke university. My team and I have been working on > building peripherals that turn the laptop into a medical monitoring device, > and Michail Blesetas was kind enough to send us a few of the first boards. > My software guys are out of the country right now, and although I have a > background in biomedical engineering I my self am not a programmer. Thus, my > question is what do I need to do / download in order to get the laptop to > boot up off a flash USB drive? I can probably figure out the details, but I > could use a general roadmap on what I should do. Zach, Please refer to http://wiki.laptop.org/go/Installing_Fedora_Core
Date: August 31, 2006
From: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
In-reply-to:
<42bbb5c30608300604q6055c50ehfff440dd8c55cdd8@xxxxxxxxxxxxxx>
References:
<42bbb5c30608300529r1536f282v605773d7012e52ad@xxxxxxxxxxxxxx> <44F585AC.60101@xxxxxxxxxxxxxxxxxxxxxxxxx> <42bbb5c30608300547p1bf8ea55gad78f7a568ade484@xxxxxxxxxxxxxx> <44F58BED.1090208@xxxxxxxxxxxxxxxxxxxxxxxxx> <42bbb5c30608300604q6055c50ehfff440dd8c55cdd8@xxxxxxxxxxxxxx>
On Wed, Aug 30, 2006 at 10:04:21AM -0300, Marcos Barbosa wrote: > Thanks. You know why i report wifi network card driver bugs? Ola Marcos, Are you completly sure that the network driver does not detect your card? Issue is that, upon a failure in an attempt to load the firmware, the driver will reset the wifi device, then reset the USB connection, and retry (which is flawless from my experience, even though it reports "usb8xxx: probe of 1-4:1.0 failed with error -12" once or twice). Can you please confirm that, after the initial failed probe report, "iwconfig" reports no presence of the wifi device? Thanks. > 2006/8/30, Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx>: > >Marcos Barbosa wrote: > >> Sorry. This is rev-B board (with serial number). > > > >We haven't shipped rev-B boards yet. If you got it through the standard > >developer program, it's a rev-A. > > > >> I use default BIOS version. > > > >Okay, so you're still using the Insyde BIOS (the one with the white > >bootup screen and the big Insyde logo)? > > > >If so, I would suggest you wait a few days. We're trying to push out a > >LinuxBIOS release today or tomorrow. We can look at the issue if it > >persists after you upgrade. > > > >-- > >Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx> | GPG: 0x147C722D > > > > > -- > Abraços > Marcos Henrique Esteves Barbosa > marcosestevesbarbosa@xxxxxxxxx > _______________________________________________ > Devel mailing list > Devel@xxxxxxxxxx > http://mailman.laptop.org/mailman/listinfo/devel
Date: August 30, 2006
From: Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx>
In-reply-to:
<1156906248.7974.21.camel@xxxxxxxxxxxxxxxxxxxxx>
References:
<1156906248.7974.21.camel@xxxxxxxxxxxxxxxxxxxxx>
Jim Gettys wrote: > I recommend reading through this paper carefully. While we're on the topic of papers to read and take to heart, the writing that left the single biggest impression on my thoughts on real-world software engineering was Tom Davis' now (in)famous internal SGI memo that was circulated after the '93 disaster that was IRIX 5.1. http://www.art.net/~hopkins/Don/unix-haters/tirix/embarrassing-memo.html Still an indispensable read. -- Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx> | GPG: 0x147C722D
Date: August 30, 2006
From: Matthew Garrett <mjg59@xxxxxxxxxxxxx>
In-reply-to:
<EB12A50964762B4D8111D55B764A845484D316@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<EB12A50964762B4D8111D55B764A845484D316@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Wed, Aug 30, 2006 at 11:40:16AM -0700, Pallipadi, Venkatesh wrote: (Added devel@xxxxxxxxxx to the Cc:) > While we are at cleaning up the code, I think it will be much better to > move out C-state policy out of this acpi code altogether. We should have That would be helpful. For the One Laptop Per Child project (or whatever it's called today), it would be advantageous to run without acpi. At the moment that would cost us deeper C states, so an interface to allow a platform driver to register and provide the same functionality without code duplication would be helpful. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
Date: August 30, 2006
From: "Marcos Barbosa" <marcosestevesbarbosa@xxxxxxxxx>
In-reply-to:
<44F58BED.1090208@xxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<42bbb5c30608300529r1536f282v605773d7012e52ad@xxxxxxxxxxxxxx> <44F585AC.60101@xxxxxxxxxxxxxxxxxxxxxxxxx> <42bbb5c30608300547p1bf8ea55gad78f7a568ade484@xxxxxxxxxxxxxx> <44F58BED.1090208@xxxxxxxxxxxxxxxxxxxxxxxxx>
Thanks. You know why i report wifi network card driver bugs? 2006/8/30, Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx>:
Marcos Barbosa wrote: > Sorry. This is rev-B board (with serial number). We haven't shipped rev-B boards yet. If you got it through the standard developer program, it's a rev-A. > I use default BIOS version. Okay, so you're still using the Insyde BIOS (the one with the white bootup screen and the big Insyde logo)? If so, I would suggest you wait a few days. We're trying to push out a LinuxBIOS release today or tomorrow. We can look at the issue if it persists after you upgrade. -- Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx> | GPG: 0x147C722D
-- Abraços Marcos Henrique Esteves Barbosa marcosestevesbarbosa@xxxxxxxxx
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: August 30, 2006
From: Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx>
In-reply-to:
<42bbb5c30608300547p1bf8ea55gad78f7a568ade484@xxxxxxxxxxxxxx>
References:
<42bbb5c30608300529r1536f282v605773d7012e52ad@xxxxxxxxxxxxxx> <44F585AC.60101@xxxxxxxxxxxxxxxxxxxxxxxxx> <42bbb5c30608300547p1bf8ea55gad78f7a568ade484@xxxxxxxxxxxxxx>
Marcos Barbosa wrote: > Sorry. This is rev-B board (with serial number). We haven't shipped rev-B boards yet. If you got it through the standard developer program, it's a rev-A. > I use default BIOS version. Okay, so you're still using the Insyde BIOS (the one with the white bootup screen and the big Insyde logo)? If so, I would suggest you wait a few days. We're trying to push out a LinuxBIOS release today or tomorrow. We can look at the issue if it persists after you upgrade. -- Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx> | GPG: 0x147C722D
Date: August 30, 2006
From: "Marcos Barbosa" <marcosestevesbarbosa@xxxxxxxxx>
In-reply-to:
<44F585AC.60101@xxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<42bbb5c30608300529r1536f282v605773d7012e52ad@xxxxxxxxxxxxxx> <44F585AC.60101@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sorry. This is rev-B board (with serial number). I use default BIOS version. This problem is in BIOS? not in driver? is easy recreate bug. 2006/8/30, Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx>:
Marcos Barbosa wrote: > I detect strange and terrible bug in wifi network card driver. The > module not load if laptop reboot. To clarify: by 'laptop', you're talking about the rev-A board? What BIOS are you running? > Please, report the bug, i not time to this. That's really not appropriate. Filing a bug takes less time than writing an e-mail; if you honestly don't have time to do it, you should not have signed up for the developer board program. Please file the bug. -- Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx> | GPG: 0x147C722D
-- Abraços Marcos Henrique Esteves Barbosa marcosestevesbarbosa@xxxxxxxxx
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: August 30, 2006
From: Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx>
In-reply-to:
<42bbb5c30608300529r1536f282v605773d7012e52ad@xxxxxxxxxxxxxx>
References:
<42bbb5c30608300529r1536f282v605773d7012e52ad@xxxxxxxxxxxxxx>
Marcos Barbosa wrote: > I detect strange and terrible bug in wifi network card driver. The > module not load if laptop reboot. To clarify: by 'laptop', you're talking about the rev-A board? What BIOS are you running? > Please, report the bug, i not time to this. That's really not appropriate. Filing a bug takes less time than writing an e-mail; if you honestly don't have time to do it, you should not have signed up for the developer board program. Please file the bug. -- Ivan Krstić <krstic@xxxxxxxxxxxxxxxxxxxxxxxxx> | GPG: 0x147C722D
Date: August 30, 2006
From: "Marcos Barbosa" <marcosestevesbarbosa@xxxxxxxxx>
I detect strange and terrible bug in wifi network card driver. The module not load if laptop reboot. I power up the laptop and module load, but i reset and module not load. Please, report the bug, i not time to this. Error is: usb8xxx: probe of 1-4:1.0 failed with error -12 Sorry my english, because i am brazilian;-) Thanks Marcos Henrique Esteves Barbosa marcosestevesbarbosa@xxxxxxxxx
Date: August 30, 2006
From: Joshua N Pritikin <jpritikin@xxxxxxxxx>
In-reply-to:
<1156867338.5961.55.camel@xxxxxxxxxxxxxxxxxxxxx>
References:
<1156867338.5961.55.camel@xxxxxxxxxxxxxxxxxxxxx>
On Tue, Aug 29, 2006 at 12:02:18PM -0400, Jim Gettys wrote: > "Belt and Suspenders" feels right to me. Even if kids are going to blindly follow directions about "Hold this key combo down to reflash the BIOS", that's good because then they'll know that _something_ is happening. Mystery invites investigation. More kids will discover the BIOS and its humble purpose.
signature.asc
Description: Digital signature
_______________________________________________ Devel mailing list Devel@xxxxxxxxxx http://mailman.laptop.org/mailman/listinfo/devel
Date: August 30, 2006
From: "Richard Smith" <smithbone@xxxxxxxxx>
rev_a_20060830-1 "Bugs are good" Highlights. - use quilt for patches - Switch back to march=i586 - possible warmboot fix - refactored LinuxBIOS pull system that also does local patches The LB build refactor was tested by a wopping 2 people and I was one of them. So YMMV. -- Richard A. Smith
Date: August 30, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<032.0a6961cbcc12ea1b5761d34ac3e376bd@xxxxxxxxxx>
References:
<032.0a6961cbcc12ea1b5761d34ac3e376bd@xxxxxxxxxx>
#68: Network adapter causes 20% slowdown
------------------------------------+---------------------------------------
Reporter: yoshiki@xxxxxxxxxxxxxx | Owner: jg
Type: defect | Status: new
Priority: normal | Milestone:
Component: kernel | Resolution:
Keywords: |
------------------------------------+---------------------------------------
Comment (by arnd):
Replying to [comment:3 krstic]:
I when working on the mcs7830 usbnet driver, I saw a number of bad effects
on the OLPC board:
* The status interrupt keeps rearming itself, which results in an
interrupt storm. Please watch your /proc/interrupts file to
see how many USB interrupts you get on an idle system with and without the
network adapter.
* In some configurations, my adapter is rather unstable and generates
error packets even if there is no data being transferred.
Using an active hub solved that for me. Please attach the output of
'ifconfig' to see if you have errors.
* The usbnet infrastructure is not as optimal as it could be and uses lots
of cycles in softirq context. I could never manage to transfer more than
7MB/s because of that. It's not directly related to this problem, but we
may want to profile this anyway.
--
Ticket URL: <http://dev.laptop.org/ticket/68#comment:4>
One Laptop Per Child <http://laptop.org/>
Date: August 30, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<032.0a6961cbcc12ea1b5761d34ac3e376bd@xxxxxxxxxx>
References:
<032.0a6961cbcc12ea1b5761d34ac3e376bd@xxxxxxxxxx>
#68: Network adapter causes 20% slowdown
------------------------------------+---------------------------------------
Reporter: yoshiki@xxxxxxxxxxxxxx | Owner: jg
Type: defect | Status: new
Priority: major | Milestone:
Component: kernel | Resolution:
Keywords: |
------------------------------------+---------------------------------------
Changes (by krstic):
* owner: mlj => jg
* component: display => kernel
* reporter: wmb@xxxxxxxxxxxxx => yoshiki@xxxxxxxxxxxxxx
--
Ticket URL: <http://dev.laptop.org/ticket/68#comment:3>
One Laptop Per Child <http://laptop.org/>
Date: August 30, 2006
From: Mitch Bradley <wmb@xxxxxxxxxxxxx>
OLPC system software meeting. 2006-08-29 Richard, Jim, Mitch (scribe), Jordan, Chris Ball, Ivan, Marcello, David Woodhouse Ivan fixed trac! Yay! Kudos to everyone for nailing several blocker bugs, details below. Mitch: The CaFe SD hardware differs quite a bit from the publicly-available "Simplified SD Host Controller Spec". Most of the data transfer registers are the same, but there are widespread differences in the miscellaneous registers that support such features as card presence detection, power control, and clock control. Dave Woodhouse has arrived in Santa Clara, will go to Marvell on Wednesday. Ticket #59 - wireless problem. Jordan and Tom nailed it! Yay! Tested by Chris Ball and Richard. It enumerated properly,and Richard did a flood ping. Going to ship a new version today.
Ticket #55 - Ext3 file system not cleaned dismounted Marcello: when kexec'ing a new kernel from USB FLASH, we don't unmount it. Olpc-boot.sh should copy it to a new location and unmount prior to kexec. The proposed solution is patch the LinuxBIOS kernel to ignore the incompatible flag on a read-only mount. This is more or less what grub already does. Action item for Marcello to develop this patch. Ticket #53: Jumping to LinuxBIOS hang: Jordan and Tom found that the first byte written to RAM comes out wrong. Apparently you need a nonce write to RAM to stabilize the PLLs. Details in the trac log. We aren't 100% sure that this is the same bug, but there's an excellent chance. The plan is to push out this fix, then be on the lookout for more instances of the hang. Marcello reports another problem with USB keys. Unmount root fs, reboot fails twice, then works the third time. Somewhat repeatable. Action item for Marcello to create a trac ticket. Action Item: David - enter a trac ticket on DCON problem (presence of DCON tends to make USB flakier). Action Item: Everybody! When you see a problem - any problem - open up a trac ticket. Bugs R Us. Every bug we find and fix now makes thousands of users happier. Marcello: why not just use bugzilla? Resolution: we'll try trac for another week, now that Ivan has improved it, and reevaluate at next week's meeting.Jordan: using FS2 on pre-A. Can we add Quanta to add jtag headers to test-B boards?
AI: Jim to request JTAG headers on first thousand test-B boards.
Date: August 30, 2006
From: Ronald G Minnich <rminnich@xxxxxxxx>
In-reply-to:
<44F3C088.6090203@xxxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20060827214001.25ABB3E61A4@xxxxxxxxxxxxxxxxxxxxxxxxx> <44F21657.6050304@xxxxxxxxxxxxxxxxxxxxxxxxx> <8a0c36780608271730p5469c3edx8910daef2efd9a09@xxxxxxxxxxxxxx> <44F23D38.9080604@xxxxxxxxxxxxxxxxxxxxxxxxx> <44F3B3A9.10704@xxxxxxxx> <44F3B9BD.4050404@xxxxxxxxxxxxxxxxxxxxxxxxx> <44F3BB56.7080203@xxxxxxxx> <44F3BE0F.7020202@xxxxxxxxxxxxxxxxxxxxxxxxx> <44F3BEF8.8020404@xxxxxxxx> <44F3C088.6090203@xxxxxxxxxxxxxxxxxxxxxxxxx>
Ivan Krstić wrote:
Ronald G Minnich wrote:in the case that you changed your mind, for whatever reason, but the reboot happened before you had a chance to unwind the decision to flash.In what circumstances do you foresee an OLPC user changing his mind about flashing the BIOS? This is the same question I asked Daniel. It's not rhetorical.
In unforeseen circumstances, which by definition, can not be foreseen :-)I am somewhat tongue in cheek here, and I am trying to remember which system I used long ago that did this 'take action on reboot', and why it was an issue. But .... I can't.
Anyways, I think the decision on this one is probably out of my domain, so I will not worry too much about it :-)
thanks ron
Date: August 30, 2006
From: Daniel Walker <dwalker@xxxxxxxxxx>
In-reply-to:
<20060830025442.GA8473@dmt
>
References:
<1156900799.15339.55.camel@xxxxxxxxxxxxxxxxxxx> <20060830025442.GA8473@dmt
>
On Tue, 2006-08-29 at 23:54 -0300, Marcelo Tosatti wrote: > However, latest patch is still http://lkml.org/lkml/2006/6/4/169 > > Current TODO: > > * Condition CONFIG_GC_SECTIONS on presence of a recent binutils > * Extra config option to allow for non used exported symbols to be swept > (must be > non default behaviour) > * Recursive make invocation from Makefile is sort of ugly, Makefile changes > can beautified. > * Do the same as done for ksymtab* to kcrctab* (CONFIG_MODVERSIONS) > * Cover other architectures with KEEP() directives > > After fixing those trivial items garbage collection should be ready for > mainline merge. > Ok. I'll see if I can accomplish some of this. Thanks for the hints. Daniel
Date: August 30, 2006
From: Marcelo Tosatti <mtosatti@xxxxxxxxxx>
In-reply-to:
<1156900799.15339.55.camel@xxxxxxxxxxxxxxxxxxx>
References:
<1156900799.15339.55.camel@xxxxxxxxxxxxxxxxxxx>
On Tue, Aug 29, 2006 at 06:19:59PM -0700, Daniel Walker wrote: > Hi, > > I was wondering what happened to this patch? Have you created a better > version, or was the response to soft that you aren't working on it? Hi Daniel, I will certainly continue to enhance the patch. Although I'm pretty busy this week (help on the TODO items is welcome!) What been done since the last submission to lkml: * The --print-gc-sections patch has been merged to binutils CVS. * end_rodata issue has been fixed and merged to mainline. However, latest patch is still http://lkml.org/lkml/2006/6/4/169 Current TODO: * Condition CONFIG_GC_SECTIONS on presence of a recent binutils * Extra config option to allow for non used exported symbols to be swept (must be non default behaviour) * Recursive make invocation from Makefile is sort of ugly, Makefile changes can beautified. * Do the same as done for ksymtab* to kcrctab* (CONFIG_MODVERSIONS) * Cover other architectures with KEEP() directives After fixing those trivial items garbage collection should be ready for mainline merge.
Date: August 30, 2006
From: Jim Gettys <jg@xxxxxxxxxx>
Doug Clark wrote a paper called "Bugs are good"; it is hard to find, but some of the material can be found in his paper: "Large-Scale Hardware Simulation: Modeling and Verification Strategies", which you can find at: http://inst.eecs.berkeley.edu/~cs152/fa05/handouts/clark-test.pdf While specifically discussing design and testing of systems, much of what Doug says in this document is of wide applicability. I recommend reading through this paper carefully. It is the attitude shift that bugs and resolving them are a sign of progress that is most important to take away from it. Many of the ideas have direct applicability to software as well as hardware. I would like to encourage everyone on the project to take this to heart: every bug we find now is one less we'll deal with, and probably thousands or even millions of people will not suffer from. Do not sweep bugs, particularly possible hardware bugs, under the carpet. Get them into the bug tracking system, where we won't forget them, and make sure the hardware information gets captured. Bugs are good..... And now back to our regularly scheduled program, - Jim -- Jim Gettys One Laptop Per Child
Date: August 30, 2006
From: "Zarro Boogs per Child" <bugtracker@xxxxxxxxxx>
In-reply-to:
<047.4e61d2feb0a831ef72f23bd2a571146e@xxxxxxxxxx>
References:
<047.4e61d2feb0a831ef72f23bd2a571146e@xxxxxxxxxx>
#27: Stress tester.
----------------------+-----------------------------------------------------
Reporter: jg | Owner: wmb@xxxxxxxxxxxxx
Type: defect | Status: new
Priority: critical | Milestone: alpha
Component: hardware | Resolution:
Keywords: |
----------------------+-----------------------------------------------------
Changes (by krstic):
* owner: Imran Akbar <imran@xxxxxxxxxxx> => wmb@xxxxxxxxxxxxx
Comment:
Mitch will work on this, as per the conference call from a while ago.
--
Ticket URL: <http://dev.laptop.org/ticket/27#comment:1>
One Laptop Per Child <http://laptop.org/>