[moving to coreboot@]
On 15.05.2009 00:58, Ward Vandewege wrote:
On Thu, May 14, 2009 at 11:13:45PM +0200, Carl-Daniel Hailfinger wrote:
Can you please run flashrom -V and mail the output to us? This will help us to add support for your chip.
On 14.05.2009 23:00, wangji wrote:
./flashrom -r YellowPc.rom flashrom v0.9.0-r510 No coreboot table found. Found chipset "Intel ICH7/ICH7R", enabling flash write... OK. Calibrating delay loop... OK. Found chip "EON unknown EON SPI chip" (0 KB) at physical address 0x0.
Great. First time that the unknown chip logic triggered and it was immediately useful.
=== This flash part has status NOT WORKING for operations: PROBE READ ERASE WRITE Please email a report to flashrom@coreboot.org if any of the above operations work correctly for you with this flash part. Please include the full output from the program, including chipset found. Thank you for your help! ===
-> would it make sense to suggest to the user to write to us with flashrom -V output, since we want that output to debug almost all problems?
Indeed. We should also tell the user not to reboot and mail us or join IRC if any modifying operation fails.
My medium-term plan is to have flashrom read the flash before any erase or write (with opt-out possibility) and if erase fails halfway through, try to restore.
Regards, Carl-Daniel
(Please try not to full-quote.)
Carl-Daniel Hailfinger wrote:
if erase fails halfway through, try to restore.
At the very least let the user decide if they really want all those side effects. I think this will cause more problems than it solves.
//Peter
On 15.05.2009 01:43, Peter Stuge wrote:
(Please try not to full-quote.)
This was intentional because not everyone on the coreboot list is on the flashrom alias.
Carl-Daniel Hailfinger wrote:
if erase fails halfway through, try to restore.
At the very least let the user decide if they really want all those side effects. I think this will cause more problems than it solves.
That's why I wrote "with opt-out possibility".
Regards, Carl-Daniel
On Fri, May 15, 2009 at 01:52:45AM +0200, Carl-Daniel Hailfinger wrote:
On 15.05.2009 01:43, Peter Stuge wrote:
(Please try not to full-quote.)
This was intentional because not everyone on the coreboot list is on the flashrom alias.
Which should be a public mailing list, or _this_ mailing list anyway.
This closed, non-public alias is totally counter-productive if you ask me. If we want to separate that traffic from the coreboot list, fine, make it a flashrom-reports mailing list, but either way it should be public. We have nothing to hide.
Uwe.
On Fri, May 15, 2009 at 02:31:52AM +0200, Uwe Hermann wrote:
On Fri, May 15, 2009 at 01:52:45AM +0200, Carl-Daniel Hailfinger wrote:
On 15.05.2009 01:43, Peter Stuge wrote:
(Please try not to full-quote.)
This was intentional because not everyone on the coreboot list is on the flashrom alias.
Which should be a public mailing list, or _this_ mailing list anyway.
This closed, non-public alias is totally counter-productive if you ask me. If we want to separate that traffic from the coreboot list, fine, make it a flashrom-reports mailing list, but either way it should be public. We have nothing to hide.
Time for a general flashrom mailing list to which the reports could go?
Thanks, Ward.
On 15.05.2009 02:35, Ward Vandewege wrote:
On Fri, May 15, 2009 at 02:31:52AM +0200, Uwe Hermann wrote:
On Fri, May 15, 2009 at 01:52:45AM +0200, Carl-Daniel Hailfinger wrote:
On 15.05.2009 01:43, Peter Stuge wrote:
(Please try not to full-quote.)
This was intentional because not everyone on the coreboot list is on the flashrom alias.
Which should be a public mailing list, or _this_ mailing list anyway.
This closed, non-public alias is totally counter-productive if you ask me. If we want to separate that traffic from the coreboot list, fine, make it a flashrom-reports mailing list, but either way it should be public. We have nothing to hide.
Time for a general flashrom mailing list to which the reports could go?
That means we need a moderator (against the spam) and we need to make people aware that their e-mail address and all mail contents will be public.
I don't know of anyone who has enough time for moderation and can guarantee low delays. After all, people may mail us if flashing failed, hoping for assistance.
Regards, Carl-Daniel
On Fri, May 15, 2009 at 02:54:01AM +0200, Carl-Daniel Hailfinger wrote:
On 15.05.2009 02:35, Ward Vandewege wrote:
Time for a general flashrom mailing list to which the reports could go?
That means we need a moderator (against the spam) and we need to make
If only subscribed people are allowed to post, there is little work to be done for real.
people aware that their e-mail address and all mail contents will be public.
Isn't this a given anyway with most free software related mailing lists?
I am left wondering why this would be an issue at all?
I don't know of anyone who has enough time for moderation and can guarantee low delays.
What is there that needs to be moderated? Just the non-subscribed posts need to be cleared out from time to time. If you have an autoresponse to tell people to subscribe and repost their valid questions, then even that doesn't need to be a high frequency thing.
Again, why is this being brought up/worried about?
After all, people may mail us if flashing failed, hoping for assistance.
s/may/will and should/
I don't think flashrom getting its own mailinglist is going to confuse people (quite the contrary), or is going to create a shortlived mailinglist, or is uselessly going to split up the flow of information or is going to diffuse communication. I believe that the current state and development pace of flashrom, and the massively growing and grown userbase warrant a flashrom@coreboot.org. It all depends on how much work this is to set up on coreboot.org.
Luc Verhaegen.
On 15.05.2009 14:58, Luc Verhaegen wrote:
On Fri, May 15, 2009 at 02:54:01AM +0200, Carl-Daniel Hailfinger wrote:
If only subscribed people are allowed to post, there is little work to be done for real.
subscriber-only mailing lists are a too high barrier for someone who wants to mail just one report.
people aware that their e-mail address and all mail contents will be public.
Isn't this a given anyway with most free software related mailing lists?
I am left wondering why this would be an issue at all?
Unless we tell the users explicitly that flashrom@coreboot.org is a public mailing list, they have every right to assume it is not. That alias also gets complete BIOS images from time to time (at least in the past) and publishing these images in a mailing list archive is a copyright problem.
What is there that needs to be moderated? Just the non-subscribed posts need to be cleared out from time to time.
Even the most friendly message to non-subscribers will be interpreted as "Dear unsubscribed user, we will ignore your post until a moderator has time or you subscribe and repost. Even if your machine is dead, we have to enforce some behavioural standards..." Please consider that people mailing us may be under intense psychological stress due to a possibly broken system.
If you have an autoresponse to tell people to subscribe and repost their valid questions, then even that doesn't need to be a high frequency thing.
See my explanation above. Besides, an autoresponse will trigger on spam messages with fake sender as well and might get coreboot.org blacklisted.
Anyone who wants to join the current flashrom@coreboot.org alias is invited to say so.
Regards, Carl-Daniel
subscriber-only mailing lists are a too high barrier for someone who wants to mail just one report.
I agree.
What if we filter the mail by whether or not it contains the output from flashrom -V. No valid output -> deleted.
Most spammers won't care enough to figure that out, and we want that information in any mail to that list anyway.
Thanks, Myles
On Fri, May 15, 2009 at 08:01:08AM -0600, Myles Watson wrote:
subscriber-only mailing lists are a too high barrier for someone who wants to mail just one report.
I agree.
What if we filter the mail by whether or not it contains the output from flashrom -V. No valid output -> deleted.
Most spammers won't care enough to figure that out, and we want that information in any mail to that list anyway.
Why should we even care about spam? That's what spamfilters are used for, I'm sure everyone uses some of them already anyway.
The current non-public mail alias get spam _also_ FWIW, so there's no difference there either...
Uwe.
On 15.05.2009 17:32, Uwe Hermann wrote:
Why should we even care about spam? That's what spamfilters are used for, I'm sure everyone uses some of them already anyway.
If there archives, I want them to be spam-free. The difference between now (alias) and the proposal (public list) is that the spam filter would have to run on the server instead.
The current non-public mail alias get spam _also_ FWIW, so there's no difference there either...
For a simple alias, a server-side spam filter is also desirable, but it is not an absolute must as for a public mailing list.
Regards, Carl-Daniel
Uwe Hermann wrote:
the flashrom alias.
This closed, non-public alias is totally counter-productive
I don't consider it to be closed, and I don't think it should be. Anyone who wants to get on it to help users should be able to do so.
But I think there's a point in having only people on the alias, and ideally people who are comfortable tinkering with the code.
We have nothing to hide.
Agreed, but maybe others prefer to not have their logs and experiences published and archived.
I see benefits both ways, but I tend to prefer the developer alias.
//Peter
Carl-Daniel Hailfinger wrote:
(Please try not to full-quote.)
This was intentional because not everyone on the coreboot list is on the flashrom alias.
You seem to full-quote very often though. It helps (not just me; everyone!) if you trim the quotes. Also in patch reviews. Thanks.
if erase fails halfway through, try to restore.
At the very least let the user decide if they really want all those side effects.
That's why I wrote "with opt-out possibility".
I tried to explain that I think opt-in would be better.
//Peter
On 15.05.2009 04:21, Peter Stuge wrote:
You seem to full-quote very often though. It helps (not just me; everyone!) if you trim the quotes. Also in patch reviews. Thanks.
Sure, I'll watch my quote length in the future.
if erase fails halfway through, try to restore.
I tried to explain that I think opt-in would be better.
How about opt-out for reading (which is non-destructive) before writing/erasing and opt-in for automatic restore?
The read-before-write would allow flashrom to determine the exact state of flash, e.g how many blocks differ from original/new content, are they erased or random garbage.
My goal is telling the user more about what went wrong. "Erase failed partially, blocks xxx-yyy still have original content, blocks zzz are erased." "Erase failed completely, the flash chip is unchanged."
That both helps us assess the situation and may avoid panic in the "flash chip is unchanged" case.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Sure, I'll watch my quote length in the future.
Fantastic! Thanks.
if erase fails halfway through, try to restore.
I tried to explain that I think opt-in would be better.
How about opt-out for reading (which is non-destructive) before writing/erasing and opt-in for automatic restore?
I think that's good! Some extra reading doesn't matter as reading is always a required operation for verification anyway.
//Peter
On Fri, May 15, 2009 at 3:10 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
How about opt-out for reading (which is non-destructive) before writing/erasing and opt-in for automatic restore?
There are some heuristics and techniques you could do. Read it in initially makes sense. But create a file in all cases? What if they are on a readonly file system when running flashrom (which I do frequently)?
But if it is unchanged after an erase, then further action may be bad. I have had cases where the flash "seemed" to fail, but the flash part was fine. Trying to restore it might make it worse if the cause is a timing or MTRR issue. I've seen that too.
Automatic recovery is very tricky in these cases.
as for traffic such as this, I think leaving it on coreboot is fine. We are not a heavy traffic list at present.
ron
-
Carl-Daniel Hailfinger -
Luc Verhaegen -
Myles Watson -
Peter Stuge -
ron minnich -
Uwe Hermann -
Ward Vandewege