I understand that you are p****d, but here is what the Nokia Engineer has said as per bug report. There is only one specific use case that is likely to get fixed in the next firmware release (this might not be what you want to hear).

The inter-relationship between hardware and firmware is such that it is possible to fix it both in hardware and software in many cases. Right now there is a hardware fix for 32wd_to crashes, and that is to swap your device. The more devices that go back to Nokia the better chance they can sort this.

=================Nokia Engineer comments=============
This bug contains many different reboot issues.

One set of issues is system service crashes. These seems to be quite rare in
this bug though.

Another set is crashes when the device is heavily used. This could be memory
management related issue (e.g. between CPU, GPU and DSP, they all can change
the memory mappings).

One set seems to be related to power management (device wakeup from sleep) and
happening more often on some specific devices, but it may be more of a slight
difference in how they behave than "hardware bug"[1].

Last set seems to be related to networking and an Oops in network related
functionality. This may be something that triggers based on what kind of a
network environment one has or traffic that network has.

Most of them so far seem to be triggering randomly, but that doesn't mean that
it would be a HW issue. Things that depend on power management, memory
management, network environment, timings etc on the kernel side, may get
triggered seemingly randomly when the device has as complex HW and SW
interactions as what e.g. N900 has.


The important thing is to check what kind of reboot is in the question; sw_rst
or 32wd_to, whether former was because of a critical system service
termination, or whether they were because of some specific kernel oops, or
whether 32wd_to was just due to device freezing (without Oops being logged) and
provide the information in which kind of situations these happen and steps
leading to it.

Based on that information from all of you, we can then try to come up with
specific steps where some *specific* reboot cause can be nearly always be
triggered within reasonable time (say 15 mins). After that finding the cause
for the bug and fixing it becomes much easier.


[1] As to HW, every device from every manufacturer has "HW bugs", at least if
you consider any component in device working even slightly differently from its
specification as a bug. SW adapting to these is normal driver work.

Then there are variations between individual devices. HW in devices is not
100% identical, they just comply to certain set of tolerance limits and
functionality tests. Some components are calibrated at the manufacturing line
and these calibrations may also differ between devices. With the complex HW &
SW combinations & interactions & radio/network environments these small
variations may sometimes cause unexpected situations for the SW.

As to whether one could say that some issue is a "bug" in some specific device
HW, requires first determining the exact cause of the issue and whether SW can
handle that reasonably.